SQLServer优化资料整理（二）

存储过程编写经验和优化措施

　　一、适合读者对象：数据库开发程序员，数据库的数据量很多，涉及到对SP（存储过程）的优化的项目开发人员，对数据库有浓厚兴趣的人。 　

　
　二、介绍：在数据库的开发过程中，经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。如果项目的SP较多，书写
又没有一定的规范，将会影响以后的系统维护困难和大SP逻辑的难以理解，另外如果数据库的数据量大或者项目对SP
的性能要求很，就会遇到优化的问题，否则速度有可能很慢，经过亲身经验，一个经过优化过的SP要比一个性能差的SP的效率甚至高几百倍。 　

　　三、内容： 　

　　1、开发人员如果用到其他库的Table或View，务必在当前库中建立View来实现跨库操作，最好不要直接使用“databse.dbo.table_name”，因为sp_depends不能显示出该SP所使用的跨库table或view，不方便校验。　　

　　2、开发人员在提交SP前，必须已经使用set showplan on分析过查询计划，做过自身的查询优化检查。 　

　　3、高程序运行效率，优化应用程序，在SP编写过程中应该注意以下几点： 　　

　　a)SQL的使用规范：

　　　i.　尽量避免大事务操作，慎用holdlock子句，提高系统并发能力。

　　　ii.　尽量避免反复访问同一张或几张表，尤其是数据量较大的表，可以考虑先根据条件提取数据到临时表中，然后再做连接。

　　　iii.　尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该改写；如果使用了游标，就要尽量避免在游标循环中再进行表连接的操作。

　　　iv.　注意where字句写法，必须考虑语句顺序，应该根据索引顺序、范围大小来确定条件子句的前后顺序，尽可能的让字段顺序与索引顺序相一致，范围从大到小。

　　　v.　不要在where子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

　　　vi.　尽量使用exists代替select count(1)来判断是否存在记录，count函数只有在统计表中所有行数时使用，而且count(1)比count(*)更有效率。

　　　vii.　尽量使用“>=”，不要使用“>”。

　　　viii.　注意一些or子句和union子句之间的替换

　　　ix.　注意表之间连接的数据类型，避免不同类型数据之间的连接。

　　　x.　注意存储过程中参数和数据类型的关系。

　　　xi.　注意insert、update操作的数据量，防止与其他应用冲突。如果数据量超过200个数据页面（400k），那么系统将会进行锁升级，页级锁会升级成表级锁。 　　

　　b)索引的使用规范：

　　　i.　索引的创建要与应用结合考虑，建议大的OLTP表不要超过6个索引。

　　　ii.　尽可能的使用索引字段作为查询条件，尤其是聚簇索引，必要时可以通过index index_name来强制指定索引

　　　iii.　避免对大表查询时进行table scan，必要时考虑新建索引。

　　　iv.　在使用索引字段作为条件时，如果该索引是联合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用。

　　　v.　要注意索引的维护，周期性重建索引，重新编译存储过程。　　

　　c)tempdb的使用规范：

　　　i.　尽量避免使用distinct、order by、group by、having、join、cumpute，因为这些语句会加重tempdb的负担。

　　　ii.　避免频繁创建和删除临时表，减少系统表资源的消耗。

　　　iii.　在新建临时表时，如果一次性插入数据量很大，那么可以使用select into代替create table，避免log，提高速度；如果数据量不大，为了缓和系统表的资源，建议先create table，然后insert。

　　　iv.　如果临时表的数据量较大，需要建立索引，那么应该将创建临时表和建立索引的过程放在单独一个子存储过程中，这样才能保证系统能够很好的使用到该临时表的索引。

　　　 v.　如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先truncate table，然后drop table，这样可以避免系统表的较长时间锁定。

　　　 vi.　慎用大的临时表与其他大表的连接查询和修改，减低系统表负担，因为这种操作会在一条语句中多次使用tempdb的系统表。　　

　　d)合理的算法使用： 　　

　
　根据上面已提到的SQL优化技术和ASE
Tuning手册中的SQL优化内容,结合实际应用,采用多种算法进行比较,以获得消耗资源最少、效率最高的方法。具体可用ASE调优命令：set
statistics io on, set statistics time on , set showplan on 等。

解析：Microsoft SQL Server中的锁模式
在SQL Server数据库中加锁时，除了可以对不同的资源加锁，还可以使用不同程度的加锁方式，即锁有多种模式，SQL Server中锁模式包括：

1．
共享锁 SQL
Server中，共享锁用于所有的只读数据操作。共享锁是非独占的，允许多个并发事务读取其锁定的资源。默认情况下，数据被读取后，SQL
Server立即释放共享锁。例如，执行查询“SELECT * FROM
AUTHORS”时，首先锁定第一页，读取之后，释放对第一页的锁定，然后锁定第二页。这样，就允许在读操作过程中，修改未被锁定的第一页。但是，事务隔
离级别连接选项设置和SELECT语句中的锁定设置都可以改变SQL Server的这种默认设置。例如，“ SELECT * FROM
AUTHORS HOLDLOCK”就要求在整个查询过程中，保持对表的锁定，直到查询完成才释放锁定。

2．更新锁更新锁在修改操作的初始
化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象。因为使用共享锁时，修改数据的操作分
为两步，首先获得一个共享锁，读取数据，然后将共享锁升级为排它锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个事务申请了共享锁，在修

改数据的时候，这些事务都要将共享锁升级为排它锁。这时，这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申
请更新锁，在数据修改的时候再升级为排它锁，就可以避免死锁。

3．排它锁 排它锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。

4．
结构锁 执行表的数据定义语言 (DDL) 操作（例如添加列或除去表）时使用架构修改 (Sch-M) 锁。当编译查询时，使用架构稳定性
(Sch-S) 锁。架构稳定性 (Sch-S)
锁不阻塞任何事务锁，包括排它锁。因此在编译查询时，其它事务（包括在表上有排它锁的事务）都能继续运行。但不能在表上执行 DDL 操作。

5．
意向锁 意向锁说明SQL
Server有在资源的低层获得共享锁或排它锁的意向。例如，表级的共享意向锁说明事务意图将排它锁释放到表中的页或者行。意向锁又可以分为共享意向锁、

独占意向锁和共享式独占意向锁。共享意向锁说明事务意图在共享意向锁所锁定的低层资源上放置共享锁来读取数据。独占意向锁说明事务意图在共享意向锁所锁定
的低层资源上放置排它锁来修改数据。共享式排它锁说明事务允许其他事务使用共享锁来读取顶层资源，并意图在该资源低层上放置排它锁。

6．
大容量更新锁 当将数据大容量复制到表，且指定了 TABLOCK 提示或者使用 sp_tableoption 设置了 table lock on
bulk 表选项时，将使用大容量更新锁。大容量更新锁允许进程将数据并发地大容量复制到同一表，同时防止其它不进行大容量复制数据的进程访问该表。

详细介绍优化SQL Server 2000的设置
　
　SQL
Server已经为了优化自己的性能而进行了良好的配置，比今天市场其他的关系型数据库都要好得多。然而，你仍然有几项设置需要进行修改，以便你的数据库

每分钟可以处理更多的事务(TPM)。本篇文章的目的就是讨论这些设置。我们忽略那些可以通过硬件配置或者表或者索引设计提高的性能，因为这些内容在本篇
文章范围之外。

　　破碎页面检测

　　在我们开始讨论服务器配置开关之前，让我们快速浏览一下你的模型数据库--或者说用作构建新的数据库的基础的模板。默认情况下，你可以在数据库中创建存储过程、函数等类似的东西，随后他们将会被加入新创建的数据库中。

　
　要优化性能，你也许想要关闭模型数据库中的破碎页面检测。当一个页面被成功写入磁盘的时候，破碎页面检测进行识别。如果激活了的话，你可以看到
每个写操作对性能产生的每个细小的影响。大多数现代的磁盘阵列都有板上电池，使得阵列可以在突然断电的情况下完成所有的写操作--引起破碎页面的最频繁原
因。

　　以下的步骤可以接受如何关闭破碎页面检测:

exec sp_dboption 'model', 'torn page detection', 'false'

　　这篇基础知识资源可以为你提供更多有关这个设置的信息。
　　大多数的配置是通过系统存储过程sp_configure完成的。要显示服务器的全部设置列表以便定制，你可以输入如下命令:

　sp_configure 'show advanced options', 1

　　GO

　　RECONFIGURE WITH OVERRIDE

　　你可以配置的选项的数量根据你的SQL Server的版本、服务包，以及位数版本(64位的SQL Server比32位的选项要多)而定。我将直接讨论最能影响SQL Server性能优化的选项。

　 　Affinity mask: Affinity mask让你可以控制SQL Server使用哪个处理器。对于大多数情况，你不应该接触这个设置，让操作系统控制处理器关系。然而，你也许想要用这个选项来将某个处理器专门用于另一 个进程(例如，MSSearch 或者 SQL Server磁盘 IO ，以及 SQL Server的平衡)。参考基础知识资源获取更多有关这个设置的信息。

　　Awe enabled: Awe的启动可以让SQL Server Enterprise版本运行在Windows 2000以及以上高级服务器上，或者Windows 2003 Enterprise以及以上的版本使用超过4GB的内存。如果你的服务器符合这些条件的话，就激活这个设置吧。

　　并行成本极限:当查询需要进行并行处理的时候，并行的成本极限就定下来了。默认情况是五秒钟。将这个数值改为稍低的数值，俄可以让更多个查询获得并行处理，但是这也会引起CPU瓶颈。这个设置只有在多个处理器的机器上才会起作用。

　　填充因子:填充因子设置了在创建聚簇索引的时候用来自动填充的因子。在频繁插入的表中，将数值从默认的90%设置为较低的数值，你会获得收益。

　　轻量级缓冲池:这个设置启动了光纤模式。使用这个选项在CPU利用率很高的8路及其以上的服务器上。这可以让光纤同时为每个线程提供服务，同时在默认情况下运行在每个处理器上。某些任务可以从这些光纤中获得优势。

　　并行的最大程度:当服务器可以使用并行或者不能使用并行，或者是当某个数量的处理器可以用于并行操作的时候，这个设置就确定了。并行就是多个处理器上发生多个处理。例如，查询的并行操作可以在不同的处理器上同时处理。

　　服务器最大内存(MB):如果你在SQL Server上运行了其他的处理，并且有足够的内存，那么你有可能想要留出512MB的内存给操作系统和这些进程。例如，你可以在MSSearch或者在本地运行大量的代理的情况下将其设置为512。
最
大工作线程:最大工作线程设置与ADO.net中的连接池有些类似。通过这个设置，任何超过限制(255个用户)的用户连接都可以在线程池中等待，直到
为某个连接服务的线程得到释放，就好像是ADO.net中的连接与连接池共享。如果你有很大量的连接，并且大量的内存，那么你就可以提高这个数值。

　　网络包尺寸(B):这个设置控制了网络中传输到你的客户端的包的尺寸。在有损耗的网络中(例如电话线)，你可能想要将这个参数设置为比较低的数值，墨人数值是4096。在连接良好的网络中，你可以提高这个设置，特别是涉及BLOB的大型批处理操作。

　　优先推进:这个设置为SQL Server提供了处理器的推动。在任务管理器中，点击进程标签，定位SQL Server的位置，然后右击它。选择“设置优先级别”。注意，SQL Server应该运行在正常的优先级别上。输入如下命令:

　 1 　Sp_configure 'priority boost', 1 2 3 　　Reconfigure with override

　　然后重新启动你的SQL Server。在任务管理器中察看SQL Server现在运行在什么优先级别上。它应该是在高优先级上。SQL Server应该比其他的用户进程运行优先级别要高。在专用于SQL Server的服务器上使用这个设置。

总结

　　本篇讨论了最常见的SQL Server优化设置。在做出改变之前和之后分别在测试环境中进行基线确定是非常重要的，可以据此来评估在典型的负载下，改变对你的系统的影响。
SQL Server 数据库中关于死锁的分析

SQL Server数据库发生死锁时不会像ORACLE那样自动生成一个跟踪文件。有时可以在[管理]->[当前活动] 里看到阻塞信息(有时SQL Server企业管理器会因为锁太多而没有响应).

设定跟踪1204:

1 USE MASTER 2 3 DBCC TRACEON (1204,-1)

显示当前启用的所有跟踪标记的状态:

DBCC TRACESTATUS(-1)

取消跟踪1204:

DBCC TRACEOFF (1204,-1)

在设定跟踪1204后,会在数据库的日志文件里显示SQL Server数据库死锁时一些信息。但那些信息很难看懂,需要对照SQL Server联机丛书仔细来看。根据PAG锁要找到相关数据库表的方法:

DBCC TRACEON (3604)
DBCC PAGE (db_id,file_id,page_no)
DBCC TRACEOFF (3604)

请参考sqlservercentral.com上更详细的讲解.但又从CSDN学到了一个找到死锁原因的方法。我稍加修改, 去掉了游标操作并增加了一些提示信息,写了一个系统存储过程sp_who_lock.sql。代码如下：

1 if exists (select * from dbo.sysobjects
2 where id = object_id(N'[dbo].[sp_who_lock]')
3 and OBJECTPROPERTY(id, N'IsProcedure') = 1)
4 drop procedure [dbo].[sp_who_lock]

需要的时候直接调用:

sp_who_lock

就可以查出引起死锁的进程和SQL语句.

SQL Server自带的系统存储过程sp_who和sp_lock也可以用来查找阻塞和死锁, 但没有这里介绍的方法好用。如果想知道其它tracenum参数的含义,请看www.sqlservercentral.com文章

我们还可以设置锁的超时时间(单位是毫秒), 来缩短死锁可能影响的时间范围:

例如:

1 use master
2 seelct @@lock_timeout
3 set lock_timeout 900000
4 -- 15分钟
5 seelct @@lock_timeout

优化SQLServer索引的小技巧
SQL Server中有几个可以让你检测、调整和优化SQL Server性能的工具。在本文中，我将说明如何用SQL Server的工具来优化数据库索引的使用，本文还涉及到有关索引的一般性知识。

关于索引的常识

影响到数据库性能的最大因素就是索引。由于该问题的复杂性，我只可能简单的谈谈这个问题，不过关于这方面的问题，目前有好几本不错的书籍可供你参 阅。我在这里只讨论两种SQL Server索引，即clustered索引和nonclustered索引。当考察建立什么类型的索引时，你应当考虑数据类型和保存这些数据的 column。同样，你也必须考虑数据库可能用到的查询类型以及使用的最为频繁的查询类型。

索引的类型

如果column保存了高度相关的数据，并且常常被顺序访问时，最好使用clustered索引，这是因为如果使用clustered索引，SQL Server会在物理上按升序（默认）或者降序重排数据列，这样就可以迅速的找到被查询的数据。同样，在搜寻控制在一定范围内的情况下，对这些 column也最好使用clustered索引。这是因为由于物理上重排数据，每个表格上只有一个clustered索引。

与上面情况相反，如果columns包含的数据相关性较差，你可以使用nonculstered索引。你可以在一个表格中使用高达249个nonclustered索引--尽管我想象不出实际应用场合会用的上这么多索引。

当表格使用主关键字（primary keys），默认情况下SQL Server会自动对包含该关键字的column(s)建立一个独有的cluster索引。很显然，对这些column(s)建立独有索引意味着主关键字 的唯一性。当建立外关键字（foreign key）关系时，如果你打算频繁使用它，那么在外关键字cloumn上建立nonclustered索引不失为一个好的方法。如果表格有 clustered索引，那么它用一个链表来维护数据页之间的关系。相反，如果表格没有clustered索引，SQL Server将在一个堆栈中保存数据页。

数据页

当索引建立起来的时候，SQLServer就建立数据页（datapage），数据页是用以加速搜索的指针。当索引建立起来的时候，其对应的填充因 子也即被设置。设置填充因子的目的是为了指示该索引中数据页的百分比。随着时间的推移，数据库的更新会消耗掉已有的空闲空间，这就会导致页被拆分。页拆分 的后果是降低了索引的性能，因而使用该索引的查询会导致数据存储的支离破碎。当建立一个索引时，该索引的填充因子即被设置好了，因此填充因子不能动态维 护。

为了更新数据页中的填充因子，我们可以停止旧有索引并重建索引，并重新设置填充因子（注意：这将影响到当前数据库的运行，在重要场合请谨慎使用）。 DBCC INDEXDEFRAG和DBCC DBREINDEX是清除clustered和nonculstered索引碎片的两个命令。INDEXDEFRAG是一种在线操作（也就是说，它不会阻 塞其它表格动作，如查询），而DBREINDEX则在物理上重建索引。在绝大多数情况下，重建索引可以更好的消除碎片，但是这个优点是以阻塞当前发生在该 索引所在表格上其它动作为代价换取来得。当出现较大的碎片索引时，INDEXDEFRAG会花上一段比较长的时间，这是因为该命令的运行是基于小的交互块 （transactional block）。

填充因子

当你执行上述措施中的任何一个，数据库引擎可以更有效的返回编入索引的数据。关于填充因子（fillfactor）话题已经超出了本文的范畴，不过我还是提醒你需要注意那些打算使用填充因子建立索引的表格。

在执行查询时，SQL Server动态选择使用哪个索引。为此，SQL Server根据每个索引上分布在该关键字上的统计量来决定使用哪个索引。值得注意的是，经过日常的数据库活动（如插入、删除和更新表格），SQL Server用到的这些统计量可能已经“过期”了，需要更新。你可以通过执行DBCC SHOWCONTIG来查看统计量的状态。当你认为统计量已经“过期”时，你可以执行该表格的UPDATE STATISTICS命令，这样SQL Server就刷新了关于该索引的信息了。

建立数据库维护计划

SQL Server提供了一种简化并自动维护数据库的工具。这个称之为数据库维护计划向导（Database Maintenance Plan Wizard ，DMPW）的工具也包括了对索引的优化。如果你运行这个向导，你会看到关于数据库中关于索引的统计量，这些统计量作为日志工作并定时更新，这样就减轻了 手工重建索引所带来的工作量。如果你不想自动定期刷新索引统计量，你还可以在DMPW中选择重新组织数据和数据页，这将停止旧有索引并按特定的填充因子重 建索引。
Sybase SQL Server索引的使用和优化 
　　在应用系统中,尤其在联机事务处理系统中,对数据查询及处理速度已成为衡 量应用系统成败的标准。而采用索引来加快数据处理速度也成为广大数据库用户所 接受的优化方法。

　　在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引 提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。所以如果建 立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在 适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就 SQL Server索引的性能问题进行了一些分析和实践。

　　一、聚簇索引(clustered indexes)的使用

　　聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据 几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引，并且建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页。建立聚簇索 引的思想是：

　　1、 大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争，在一个高事务的环境中，对最后一页的封锁严重影响系统的吞吐量。

　　2、在聚簇索引下，数据在物理上按顺序排在数据页上，重复值也排在一起，因而在那些包含范围检查(between、<、<=、& gt;、> =)或使用group by或order by的查询时，一旦找到具有范围中第一个键值的行，具有后续索引值的行保证物理上毗连在一起而不必进一步搜索，避免了大范围扫描，可以大大提高查询速度。

　　3、 在一个频繁发生插入操作的表上建立聚簇索引时，不要建在具有单调上升值的列(如IDENTITY)上，否则会经常引起封锁冲突。

　　4、 在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置。

　　5、 选择聚簇索引应基于where子句和连接操作的类型。聚簇索引的侯选列是：

　　● 主键列,该列在where子句中使用并且插入是随机的。

　　● 按范围存取的列，如pri_order > 100 and pri_order < 200 。

　　● 在group by或order by中使用的列。

　　● 不经常修改的列。

　　● 在连接操作中使用的列。

　　二、非聚簇索引(nonclustered indexes)的使用

　　SQL Server缺省情况下建立的索引是非聚簇索引，由于非聚簇索引不重新组织表中的数据，而是对每一行存储索引列值并用一个指针指向数据所在的页面。换句话 说非聚簇索引具有在索引结构和数据本身之间的一个额外级。一个表如果没有聚簇索引时,可有250个非聚簇索引。每个非聚簇索引提供访问数据的不同排序顺 序。在建立非聚簇索引时，要权衡索引对查询速度的加快与降低修改速度之间的利弊。另外，还要考虑这些问题：

　　● 索引需要使用多少空间。

　　● 合适的列是否稳定。

　　● 索引键是如何选择的，扫描效果是否更佳。

　　● 是否有许多重复值。

　　对更新频繁的表来说，表上的非聚簇索引比聚簇索引和根本没有索引需要更多的额外开销。对移到新页的每一行而言，指向该数据的每个非聚簇索引的页 级行也必须更新，有时可能还需要索引页的分理。从一个页面删除数据的进程也会有类似的开销，另外，删除进程还必须把数据移到页面上部，以保证数据的连续 性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情况:

　　● 某列常用于集合函数(如Sum,....)。

　　● 某列常用于join,order by,group by。

　　● 查寻出的数据不超过表中数据量的20%。

　　三、覆盖索引(covering indexes)的使用

　　覆盖索引是指那些索引项中包含查寻所需要的全部信息的非聚簇索引，这 种索引之所以比较快也正是因为索引页中包含了查寻所必须的数据,不需去访 问数据页。 如果非聚簇索引中包含结果数据,那么它的查询速度将快于聚簇索引。

　　但是由于覆盖索引的索引项比较多,要占用比较大的空间。而且update 操 作会引起索引值改变。所以如果潜在的覆盖查询并不常用或不太关键，则覆盖索引的增加反而会降低性能。

　　四、索引的选择技术

　　p_detail是住房公积金管理系统中记录个人明细的表，有890000行，观察在不同索引下的查询运行效果，测试在C/S环境下进行，客户 机是 IBM PII350(内存64M),服务器是DEC Alpha1000A(内存128M),数据库为SYBASE11.0.3。

　　1、 select count(*) from p_detail where op_date>’19990101’ and op_date<’19991231’ and pri_surplus1>300

　　2、 select count(*),sum(pri_surplus1) from p_detail where op_date>’19990101’ and pay_month between ‘199908’ and ’199912’

　　不建任何索引 查询1 1分15秒

　　查询2 1分7秒

　　在op_date上建非聚簇索引 查询1 57秒

　　查询2 57秒

　　在op_date上建聚簇索引 查询1 <1秒

　　查询2 52秒

　　在pay_month、op_date、pri_surplus1上建索引 查询1 34秒

　　查询2 <1秒

　　在op_date、pay_month、pri_surplus1上建索引 查询1 <1秒

　　查询2 <1秒

　　从以上查询效果分析，索引的有无，建立方式的不同将会导致不同的查询效果，选择什么样的索引基于用户对数据的查询条件,这些条件体现于where从句和join表达式中。一般来说建立索引的思路是：

　　(1)、主键时常作为where子句的条件，应在表的主键列上建立聚簇索引，尤其当经常用它作为连接的时候。

　　(2)、有大量重复值且经常有范围查询和排序、分组发生的列，或者非常频繁地被访问的列，可考虑建立聚簇索引。

　　(3)、经常同时存取多列，且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询，并把查询引用最频繁的列作为前导列，如果可能尽量使关键查询形成覆盖查询。

　　(4)、如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。

　　(5)、在一个经常做插入操作的表上建索引时，使用fillfactor(填充因子)来减少页分裂，同时提高并发度降低死锁的发生。如果在只读表上建索引，则可以把fillfactor置为100。

　　(6)、在选择索引键时，设法选择那些采用小数据类型的列作为键以使每个索

　　引页能够容纳尽可能多的索引键和指针，通过这种方式，可使一个查询必须遍历的索引页面降到最小。此外，尽可能地使用整数为键值，因为它能够提供比任何数据类型都快的访问速度。

　　五、索引的维护

　　上面讲到,某些不合适的索引影响到SQL Server的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将 会影响到索引的使用。这时 需要用户自己来维护索引。索引的维护包括：

　　1、重建索引

　　随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大块I/O的时候，重建非聚簇索引可以降低分片，维护大块I/O的效率。重建索引实际上是重新组织B-树空间。在下面情况下需要重建索引：

　　(1)、数据和使用模式大幅度变化。

　　(2)、排序的顺序发生改变。

　　(3)、要进行大量插入操作或已经完成。

　　(4)、使用大块I/O的查询的磁盘读次数比预料的要多。

　　(5)、由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算。

　　(6)、dbcc检查出索引有问题。

　　当重建聚簇索引时,这张表的所有非聚簇索引将被重

　　建.

　　2、索引统计信息的更新

　　当在一个包含数据的表上创建索引的时候，SQL Server会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。优化器利用这个页来判断该索引对某个特定查询是否有用。但这个统计信息并不 动态地重新计算。这意味着，当表的数据改变之后，统计信息有可能是过时的，从而影响优化器追求最有工作的目标。因此，在下面情况下应该运行update statistics命令：

　　(1)、数据行的插入和删除修改了数据的分布。

　　(2)、对用truncate table删除数据的表上增加数据行。

　　(3)、修改索引列的值。

　　六、结束语

　　实践表明，不恰当的索引不但于事无补，反而会降低系统的执行性能。因为大量的索引在插入、修改和删除操作时比没有索引花费更多的系统时间。例如下面情况下建立的索引是不恰当的：

　　● 在查询中很少或从不引用的列不会受益于索引，因为索引很少或从来不必搜索基于这些列的行。

　　● 只有两个或三个值的列，如男性和女性(是或否)，从不会从索引中得到好处。

　　另外，鉴于索引加快了查询速度，但减慢了数据更新速度的特点。可通过在一个段上建表，而在另一个段上建其非聚簇索引，而这两段分别在单独的物理设备上来改善操作性能。