1、SQLServer语句优化1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)我们把这种 正文内容 本身就是一种按照一定规则排列 的 目录 称为“聚集索引” 。 需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的 排序方式 称为“非聚集索引”。 下面的表总结了何时使用聚集索引或非聚集索引（很重要）： 动作描述 使用聚集索引 使用非聚集索引 列经常被分组排序 应 应 返回某范围内的数据 应 不应 一个或极少不同值 不应 不应 小数目的不同值 应 不应 大数目的不同值 不应 应 频繁更新的列 不应 应 外键列 应 应 主键列
2、应 应 频繁修改索引列 不应 应 事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。 结合实际，谈索引使用的误区 理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能
3、根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。 1、主键就是聚集索引 这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。 通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。 显而易见，聚集索引的优势是很明显的，
4、而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。 从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。 在办公自动化系统中，无论是系统首页显示的需要用户签收的文件
5、、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名” 。 通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，通过“日期” 这个字段来限制表扫描，提高查询速度。如果您的办公自动化系统已经建立的2年，那么您
6、的首页显示速度理论上将是原来速度8倍，甚至更快。 在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即使您在“日期”这个字段上建立的索引（非聚合索引）。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现（3个月内的数据为25万条）： （1）仅在主键上建立聚集索引，并且不划分时间段： Select gid,fariqi,neibuyonghu,title from tgongwen用时：128470毫秒（即：128秒） （2）在主键上建立聚集索引，在fariq上建立非聚集索引： select gid,fariqi,ne
7、ibuyonghu,title from Tgongwenwhere fariqi dateadd(day,-90,getdate()用时：53763毫秒（54秒） （3）将聚合索引建立在日期列（fariqi）上： select gid,fariqi,neibuyonghu,title from Tgongwenwhere fariqi dateadd(day,-90,getdate()用时：2423毫秒（2秒） 虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有1000万容量的话，把主键建立在ID列上，就像以上
8、的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。得出以上速度的方法是：在各个select语句前加： declare d datetimeset d=getdate()并在select语句后加：select 语句执行花费时间(毫秒)=datediff(ms,d,getdate()2、只要建立索引就能显著提高查询速度 事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同；不同的仅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。所以，并非是在任何字段上简单地
9、建立索引就能提高查询速度。 从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。 3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度 上面已经谈到：在进行数据查询时都离不开字段的是“日期” 还有用户本身的“用户名” 。既然这两个字段都是如此的重要，我们可以把他们合并起来，建立一个复合索引（c
10、ompound index）。 很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）： （1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi2004-5-5 查询速度：2513毫秒（2）select gid,fariqi,neibuyonghu,title from Tgongwen wh
11、ere fariqi2004-5-5 and neibuyonghu=办公室查询速度：2516毫秒（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=办公室查询速度：60280毫秒 从以上试验中，我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的，甚至比用上全部的复合索引列还要略快（在查询结果集数目一样的情况下）；而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。当然，语句1、2的查询速度一样是因为查询的条目数一样，如果复合索引的
12、所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。 四、其他书上没有的索引使用经验总结 1、用聚合索引比用不是聚合索引的主键速度快 下面是实例语句：（都是提取25万条数据） select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16使用时间：3326毫秒select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gi
13、d2004-1-1用时：6343毫秒（提取100万条） select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi2004-6-6用时：3170毫秒（提取50万条）select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=2004-9-16用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）select gid,fariqi,neibuyonghu,reader,title from Tgong
14、wen where fariqi2004-1-1 and fariqi2004-1-1 order by fariqi用时：6390毫秒select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi非叶节点-非叶节点-叶节点（注意索引在数据库引擎中所用的内部数据结构一般是B+树，参考后文）聚集索引和非聚集索引 用一个现实中的例子说明以助理解。我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安” 字，就会很自然地翻开字典的前几页，因为“安” 的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a” 开头并以
15、“ z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“ 张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。 我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引” 。如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首” 查到您要找的字，然后根据这个字后的页码直接翻
16、到某页来找到您要找的字。但您结合“部首目录” 和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张” 字，我们可以看到在查部首之后的检字表中“张” 的页码是672页，检字表中“ 张”的上面是“驰”字，但页码却是63页，“ 张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张” 字的上下方，现在您看到的连续的“驰、张、弩” 三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为
17、“非聚集索引” 。2.性质及使用方法1)聚集索引：表中存储的数据按照索引的顺序存储，检索效率比普通索引高，索引占用硬盘存储空间小（1%左右），但对数据新增/修改/删除的速度影响比较大（降低）。特点：(1) 无索引，数据无序(2) 有索引，数据与索引同序 (3) 数据会根据索引键的顺序重新排列数据(4) 一个表只能有一个索引(5) 叶节点的指针指向的数据也在同一位置存储语法：create CLUSTERED INDEX idxempID ON emp(empID)2)非聚集索引：不影响表中的数据存储顺序，检索效率比聚集索引低，索引占用硬盘存储空间大（30%40%），对数据新增/修改/删除的影响很
18、少。特点：(1) 一个表可以最多可以创建249个非聚集索引(2) 先建聚集索引才能创建非聚集索引(3) 非聚集索引数据与索引不同序(4) 数据与非聚集索引在不同位置(5) 非聚集索引在叶节点上存储，在叶节点上有一个“指针” 直接指向要查询的数据区域(6) 数据不会根据非聚集索引键的顺序重新排列数据语法：create NONCLUSTERED INDEX idximpID ON emp(empID)创建索引的方法：1)企业管理器中(1)右击某个表，所有任务-管理索引，打开管理索引，单击“新建” 就可以创建索引(2)在设计表中进行设计表，管理索引/键(3)在关系图中，添加表后右击关系图中的某个表，
19、就有“索引/键”(4)通过向导,数据库-创建索引向导(5)通过T-SQL语句2)能过“索引优化向导”来优化索引的向导，通过它可以决定选择哪些列做为索引列何时应使用聚集索引或非聚集索引3.数据库引擎中索引的内部结构有必要先说明一下数据库引擎，这部分是较深的内容，需要有一定的数据库理论知识和数据结构与算法知识，数据结构和算法告诉我们，对索引关键字进行快速查找时要使用树形数据结构，在数据库引擎中，索引通常用B+树来表示，google发现这方面的文章较少，后面找到相关详细资料会补充。4.主键、索引、聚集索引和非聚集索引1)主键 (PK) 唯一标识表中的所有行的一个列或一组列。主键不允许空值。不能存在具
20、有相同的主键值的两个行，因此主键值总是唯一标识单个行。表中可以有不止一个键唯一标识行，每个键都称作候选键。只有一个候选键可以选作表的主键，所有其它候选键称作备用键。尽管表不要求具有主键，但定义主键是很好的做法。 在规范化的表中，每行中的所有数据值都完全依赖于主键。例如，在以 EmployeeID 作为主键的规范化的 employee 表中，所有列都应包含与某个特定职员相关的数据。该表不具有 DepartmentName 列，因为部门的名称依赖于部门 ID，而不是职员 ID。 2)索引 关系数据库中基于键值提供对表的行中数据的快速访问的数据库对象。索引还可以在表的行上强制唯一性。SQL Serv
21、er 支持聚集索引和非聚集索引。对表的主键自动进行索引。在全文搜索中，全文索引存储关于重要词和这些词在给定列中的位置的信息。 如果某列有多行包含 NULL 值，则不能在该列上创建唯一索引。同样，如果列的组合中有多行包含 NULL 值，则不能在多个列上创建唯一索引。在创建索引时，这些被视为重复的值。 3)聚集索引 在创建聚集索引时，将会对表进行复制，对表中的数据进行排序，然后删除原始的表。因此，数据库上必须有足够的空闲空间，以容纳数据复本。默认情况下，表中的数据在创建索引时排序。但是，如果因聚集索引已经存在，且正在使用同一名称和列重新创建，而数据已经排序，则会重建索引，而不是从头创建该索引，以自
22、动跳过排序操作。重建操作会检查行是否在生成索引时进行了排序。如果有任何行排序不正确，即会取消操作，不创建索引。 4)非聚集索引 非聚集索引与课本中的索引类似。数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（这可以由聚集索引规定）。如果在表中未创建聚集索引，则无法保证这些行具有任何特定的顺序。 打开设计表界面里面有个钥匙就是主键的意思，当你声明一列为主键的时候数据库实际上就是生成一个唯一的索引，查询优化器实际上是根据列上有没有唯一索引来保证列的唯一性而不是根据列是否被声明为主键。 聚集索引一个表只有一个，实
23、际上它的叶子节点就是数据页，比非聚集索引速度快，占用的空间小，大概只有表的1左右。如果在声明的时候没有选择UNIQUE选项，则在插入数据的时候会自动生成一个唯一标示符。 非聚集索引一个表可以有多个，一个3层的非聚簇索引要查询6次才可以找到真实数据，因为其叶子节点并不是真实数据，而是标识（如果表上有聚集索引则为聚集索引，如没有，则为实际数据的页号），非聚集索引通常占用空间比较大，表的3040。Microsoft SQL Server 2000 支持在表中任何列（包括计算列）上定义的索引。如果一个表没有创建索引，则数据行不按任何特定的顺序存储。这种结构称为堆集。SQL Server 索引的两种类型
24、为： 聚集 聚集索引基于数据行的键值在表内排序和存储这些数据行。由于数据行按基于聚集索引键的排序次序存储，因此聚集索引对查找行很有效。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。数据行本身构成聚集索引的最低级别。只有当表包含聚集索引时，表内的数据行才按排序次序存储。如果表没有聚集索引，则其数据行按堆集方式存储。非聚集 非聚集索引具有完全独立于数据行的结构。非聚集索引的最低行包含非聚集索引的键值，并且每个键值项都有指针指向包含该键值的数据行。数据行不按基于非聚集键的次序存储。在非聚集索引内，从索引行指向数据行的指针称为行定位器。行定位器的结构取决于数据页的存储方式是堆集还是聚集。
25、对于堆集，行定位器是指向行的指针。对于有聚集索引的表，行定位器是聚集索引键。只有在表上创建了聚集索引时，表内的行才按特定的顺序存储。这些行就基于聚集索引键按顺序存储。如果一个表只有非聚集索引，它的数据行将按无序的堆集方式存储。索引可以是唯一的，这意味着不会有两行有相同的索引键值。另外，索引也可以不是唯一的，多个行可以共享同一键值。有两种方法可以在 SQL Server 内定义索引。CREATE INDEX 语句创建并命名索引。CREATE TABLE 语句支持在创建索引时使用下列约束： PRIMARY KEY 创建唯一索引来强制执行主键。UNIQUE 创建唯一索引。CLUSTERED 创建聚集
26、索引。NONCLUSTERED 创建非聚集索引。 当在 SQL Server 2000 上创建索引时，可指定是按升序还是降序存储键。SQL Server 2000 支持在计算列上定义的索引，只要为列定义的表达式满足某些限制，如仅引用包含计算列的表中的列、具有确定性等。填充因子是 SQL Server 索引的一个属性，它控制索引在创建时的填充密度。默认的填充因子通常能够提供较好的性能，但在某些情况下，更改填充因子可能会有益。如果打算对表执行许多更新和插入，则可在创建索引时使用小填充因子，以便为后面的键留出更多的空间。如果是不会更改的只读表，则可在创建索引时使用大填充因子，以减小索引的物理大小，这
27、样可以降低 SQL Server 浏览索引时的磁盘读取次数。只有在创建索引时才能应用填充因子。随着键的插入和删除，索引最终将稳定在某个密度上。索引不仅可以提高选择行的检索速度，通常还可以提高更新和删除的速度。这是因为 SQL Server 在更新或删除行时必须先找到该行。使用索引定位行提高了效率，这通常可以弥补更新索引所需的额外开销，除非表中有很多索引。下例显示在表上创建索引的 Transact-SQL 语法。USE pubsGOCREATE TABLE emp_sample(emp_id int PRIMARY KEY CLUSTERED,emp_name char(50),emp_addr
28、ess char(50),emp_title char(25) UNIQUE NONCLUSTERED )GOCREATE NONCLUSTERED INDEX sample_nonclust ON emp_sample(emp_name)GO对于具体什么样的索引集可优化性能这个问题，取决于系统中的查询混合。考察 emp_sample.emp_id 上的聚集索引。如果大多数引用 emp_sample 的查询在它们的 WHERE 子句中有关于 emp_id 的等式或范围比较，聚集索引将发挥很好的作用。如果大多数查询的 WHERE 子句引用的是 emp_name 而非 emp_id，则通过将 em
29、p_name 上的索引置为聚集索引可提高性能。许多应用程序的查询混合都很复杂，单靠询问用户和程序员很难进行评估。SQL Server 2000 提供索引优化向导，帮助您在数据库中设计索引。对具有复杂访问模式的大型架构，最简单的设计索引的方法是使用索引优化向导。可以为索引优化向导提供一组 SQL 语句。这组语句可以是为反映系统中典型的语句混合而生成的语句脚本。不过，这组语句通常是 SQL 事件探查器跟踪记录，记录在系统典型负载期间系统上实际处理的 SQL 语句。索引优化向导分析工作负荷和数据库，然后提出可提高工作负荷性能的索引配置建议。可以选择替换现有的索引配置，或者保留现有的索引配置并实现新的
30、索引，以提高执行速度慢的查询子集的性能。2、I/O吞吐量小，形成了瓶颈效应。3、没有创建计算列导致查询不优化。computed_column_expression 是定义计算列值的表达式。计算列是物理上并不存储在表中的虚拟列。计算列由同一表中的其它列通过表达式计算得到。例如，计算列可以这样定义：cost AS price * qty。表达式可以是非计算列的列名、常量、函数、变量，也可以是用一个或多个运算符连接的上述元素的任意组合。表达式不能为子查询。 计算列可用于选择列表、WHERE 子句、ORDER BY 子句或任何其它可使用常规表达式的位置，但下列情况除外： 计算列不能用作 DEFAULT
31、 或 FOREIGN KEY 约束定义，也不能与 NOT NULL 约束定义一起使用。但是，如果计算列由具有确定性的表达式定义，并且索引列中允许计算结果的数据类型，则可将该列用作索引中的键列，或用作 PRIMARY KEY 或 UNIQUE 约束的一部分。 例如，如果表中含有整型列 a 和 b，则可以在计算列 a+b 上创建索引。但不能在计算列 a+DATEPART(dd, GETDATE() 上创建索引，因为在以后的调用中，其值可能发生改变。计算列不能作为 INSERT 或 UPDATE 语句的目标。 说明 表中计算列所使用的列值因行而异，因此每行的计算列值可能不同。 计算列的为空性是由 S
32、QL Server 根据使用的表达式自动确定的。即使只有不可为空的列，大多数表达式的结果也认为是可为空的，因为可能的下溢或溢出也将生成 NULL 结果。使用 COLUMNPROPERTY 函数（AllowsNull 属性）查看表中任何计算列的为空性。通过指定 ISNULL(check_expression, constant)，其中常量为替代任何 NULL 结果的非 NULL 值，可为空的表达式 expr 可以转换为不可为空的表达式。使用XML在SQL Server上创建计算列 在SQL Server数据库中，当你想使用一个数据，而这个数据不保存在表中，计算列很有用。例如，你有一张表，它包括列
33、dollar amounts, wholesale prices和retail prices。你肯定不想在每次查询表时来计算那两列之间的差值，你希望将其值保存在第三列中，让其自动计算前两列之间的差值。而此列就是计算列。在SQL Server中使用XML数据来创建计算列，你的列定义必须包含必要的用来检测向列中插入的是什么数据的表达式。例如，在上面的例子中，你的表达式应该从retail列中的值减去wholesale列中的值。当你添加或更新表中的数据行时，差值将自动插入至计算列中。你可以很容易地在两个或更多的包含字符串或数字类型值的列的基础上创建计算列。(更多关于如何创建此类型的计算列的详细信息，请
34、参考Microsoft SQL Server Books Online)。然而，如果你想要基于指定的XML列中元素值创建一个计算列，该过程相对更加复杂一些。因为你必须使用Xquery表达式来从XML列中获取指定元素数据,且SQL Server不支持在计算列的定义中使用Xquery表达式。要解决此问题，可以创建一个函数来接收你想包含在计算列中的XML数据，并在计算列定义中调用此函数。更好的示范这是如何工作的，我们在这给出一个例子。我在SQL Server 2005的示例数据库AdventureWorks中创建以下的架构和表:USE AdventureWorks;GOCREATE SCHEMA h
35、rGOSELECT TOP 10 JobCandidateID AS CandidateID,Resume AS JobResumeINTO hr.CandidateNamesFROM HumanResources.JobCandidateGO正如名称所示，HumanResources.JobCandidate表中的Resume列是一个XML列，它包含侯选人的履历信息。我从这张表中提取数据来创建hr架构中的CandidateNames表。(我创建了一个单独的表，因为我希望可以修改表定义，从而可以增加计算列) 在建立好测试环境后，你可以创建函数。函数应该包括在从指定的XML列中获取数据时所需的X
36、Query表达式。例如，以下函数接收工作候选人的姓名，并保存在JobResume列中：CREATE FUNCTION hr.FullName (name XML)RETURNS NVARCHAR(60) ASBEGINRETURN name.value(declare namespace ns=“http:/ “ “,(/ns:Resume/ns:Name/ns:Name.Last)1),nvarchar(60)END正如你所看到的，函数FullName带一个输入参数，该参数被定义成XML类型。这个做法是当调用此函数时，可以把包含所需提取的数据的XML列名称作为输入值来使用。Value()方法
37、带两个参数。第一个参数定义了目标XML列使用的名称空间，第二个参数包含接收实际数据的Xquery表达式。在这个例子中，表达式使用concat()方法来连接姓与名，就像它们在XML文件中。要想了解更多的关于如何使用value()方法，以及如何创建Xquery表达式，请查看我的文章Retrieve XML data values with XQuery。 一旦创建了函数，你可以通过从hr.CandidateNames表的JobResume列中接收数据测试:SELECT CandidateID, hr.FullName(JobResume) AS FullName FROM hr.Candidate
38、Names正如你所看到的，我已经传入了XML列名称，将其做为函数FullName的一个参数。SELECT语句应该返回以下结果：CandidateID FullName1 Shai Bassli2 Max Benson3 Krishna Sunkammurali4 Stephen Jiang5 Thierry DHers6 Christian Kleinerman注意，以上结果包含姓与名，正如它们在XML列中显示的一样。如果回到函数定义，可发现在value()方法中使用的Xquery表达式指定了此表达式返回值为NVARCHAR(60)类型，以适应Unicode字符，如查询结果集的最后三行中的那些
39、字符。一旦函数经过测试，你就可以开始创建计算列：以下ALTER TABLE语句添加了FullName列到CandidateNames表中来:ALTER TABLE hr.CandidateNamesADD FullName AS hr.FullName(JobResume)我已经在计算列表达式中使用FullName函数，并将列JobResume作为参数传入函数。在运行ALTER TABLE语句后，你可以用以下SELECT语句测试数据是否已经被插入到计算列中：SELECT CandidateID, FullName FROM hr.CandidateNames运行以上语句后，应该返回与上文中相同
40、的结果集。这就是在SQL Server中基于XML data数据创建的一个计算列。关键是创建一个函数来运行Xquery表达式，且稍后在计算列中使用此函数定义。要了解更多关于计算列、XML列、Xquery表达式的详细信息，请查看Microsoft SQL Server在线书籍。本文来自CSDN博客，转载请标明出处：http:/ TABLE或ALTER TABLE语句中定义的列可以源于独立的或者基于列的计算。如果需要在相关查询中对相同的数据重复计算，则计算列就变得很有用。计算列以创建表或修改表的时候定义的表达式为基础，除非使用了PERSISTED关键字，否则计算列不会物理保存在表中。在这个技巧中，
41、我会给出创建计算列的演示，并且介绍使用SQL Server 2005的PERSISTED选项的方法。通过CREATE或ALTER TABLE增加一个计算列的语法如下：column_name AS computed_column_expression PERSISTED column_name是新列的名字。computed_column_expression是你为了得到列的值而执行的计算。增加PERSISTED关键字能让计算的结果被物理保存。在这个示例中，我们向既有表中加了一个新的计算列：ALTER TABLE Production.TransactionHistory ADD CostPerU
42、nit AS (ActualCost/Quantity) 前面的示例创建了一个名为CostPerUnit的计算列。下一个查询利用它返回数量超过10的最高的CostPerUnit：SELECT TOP 1 CostPerUnit, Quantity, ActualCost FROM Production.TransactionHistory WHERE Quantity 10 ORDER BY ActualCost DESC 这个查询返回：CostPerUnit Quantity ActualCost 132.0408 13 1716.5304 下一个示例创建一个PERSISTED计算列，这意味
43、着计算后的数据实际上会物理地保存在数据库中（但仍然是由SQL Server自动计算）：CREATE TABLE HumanResources.CompanyStatistic (CompanyID int NOT NULL, StockTicker char(4) NOT NULL, SharesOutstanding int NOT NULL, Shareholders int NOT NULL, AvgSharesPerShareholder AS (SharesOutStanding/Shareholders) PERSISTED) 解析第一个示例向Production.Transact
44、ionHistory表添加了一个名为CostPerUnit的非持久化列，使它在SELECT查询中能像普通表列那样被引用：ADD CostPerUnit AS (ActualCost/Quantity) 计算列不能用DEFAULT或者FOREIGN KEY约束。计算列不能被显式更新或插入（因为它的值都是计算出的）。计算列能用在索引中，但是一定要符合一些条件。比如是确定的（对于一组给定的输入总是返回相同的结果）和精确的（不包含浮点值）。第二个示例演示了在CREATE TABLE命令中使用计算列：AvgSharesPerShareholder AS (SharesOutStanding/Shareh
45、olders) PERSISTED 和第一个示例不同，增加了PERSISTED意味着数据被物理地保存在数据库中。对计算中使用的列进行的任何修改都会引起存储值的再一次更新。但是保存的数据仍然不可以直接修改-数据仍然要经过计算。然而和非持久化的方式不同，保存数据意味着列能用于表分区（请参阅4.7.1节的“实现表分区“技巧）或者非精确（基于浮点）值的索引。4、内存不足5、网络速度慢6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)【IT专家网独家】死锁是指在某组资源中，两个或两个以上的线程在执行过程中，在争夺某一资源时而造成互
46、相等待的现象，若无外力的作用下,它们都将无法推进下去，死时就可能会产生死锁,这些永远在互相等待的进程称为死锁线程。简单的说，进程A等待进程B释放他的资源，B又等待A释放他的资源，这样互相等待就形成死锁。如在数据库中，如果需要对一条数据进行修改，首先数据库管理系统会在上面加锁，以保证在同一时间只有一个事务能进行修改操作。如事务1的线程 T1具有表A上的排它锁，事务2的线程T2 具有表B上的排它锁，并且之后需要表A上的锁。事务2无法获得这一锁，因为事务1已拥有它。事务2被阻塞，等待事务1。然后，事务1需要表B的锁，但无法获得锁，因为事务2将它锁定了。事务在提交或回滚之前不能释放持有的锁。因为事务需
47、要对方控制的锁才能继续操作，所以它们不能提交或回滚，这样数据库就会发生死锁了。如在编写存储过程的时候，由于有些存储过程事务性的操作比较频繁，如果先锁住表A，再锁住表B，那么在所有的存储过程中都要按照这个顺序来锁定它们。如果无意中某个存储过程中先锁定表B，再锁定表A，这可能就会导致一个死锁。而且死锁一般是不太容易被发现的。如果服务器上经常出现这种死锁情况，就会降低服务器的性能，所以应用程序在使用的时候，我们就需要对其进行跟踪，使用sp_who和sp_who2来确定可能是哪些用户阻塞了其他用户，我们还可以用下面的存储过程来跟踪具体的死锁执行的影响：create procedure sp_who_l
48、ockasbegindeclare spid int,bl int,intTransactionCountOnEntry int,intRowcount int,intCountProperties int,intCounter int create table #tmp_lock_who (id int identity(1,1),spid smallint,bl smallint)IF ERROR0 ) a where not exists(select * from (select * from sysprocesses where blocked0 ) b where a.blocked=spid)union select spid,blocked from sysprocesses where blocked0IF ERROR0 RETURN ERROR if intCountProperties=0select 现在没有阻塞和死锁信息 as message- 循环开始while intCounter 0 RETURN ERROR insert into #tmp_lock_who(spid,bl) se
