SQLSERVER2008R2 索引建立的几点建议

1、不要把聚集索引浪费在主键上，除非你只按主键查询

       虽然SQL SERVER默认是在主键上建立聚集索引的，但实际应用中，这样做比较浪费。通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但这样做实用价值不大。

       从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID 号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。聚集索引相对与非聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加宝贵，应该用在其他查询频率高的字段上。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。

2、索引的建立要根据实际应用需求来进行

       并非是在任何字段上简单地建立索引就能提高查询速度。聚集索引建立的规则大致是“既不能绝大多数都相同，又不能只有极少数相同”。举个例子，在公文表的收发日期字段上建立聚合索引是比较合适的。在政务系统中，我们每天都会收一些文件，这些文件的发文日期将会相同，在发文日期上建立聚合索引对性能的提升应该是相当大的。在群集索引下，数据物理上按顺序存于数据页上，重复值也排列在一起，因而在范围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提高了查询速度。

另一个相反的例子：比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就完全没必要建立索引。

3、在聚集索引中加入所有需要提高查询速度的字段，形成复合索引

       根据一些实验的结果，我们可以得出一些可供参考的结论：

       仅用复合聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询，速度是几乎一样的，甚至比后者还要快（在查询结果集数目一样的情况下）；

       仅用复合聚集索引的非起始列作为查询条件的话，

       这个索引是不起任何作用的。

       复合聚集索引的所有列都用上，而且因为查询条件严格，查询结果少的话，会形成“索引覆盖”，性能可以达到最优。

       最重要的一点：无论是否经常使用复合聚合索引的其他列，其起始列一定要是使用最频繁的列。

4.根据实践得出的一些其他经验，特定情况下有效

       用聚合索引比用不是聚合索引的主键速度快；

       用聚合索引比用一般的主键作order by速度快，特别是在小数据量情况；

      使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个；

       日期列不会因为有分秒的输入而减慢查询速度；

       由于改变一个表的内容，将会引起索引的变化。频繁的insert,update,delete语句将导致系统花费较大的代价进行索引更新，引起整体性能的下降。一般来讲，在对查询性能的要求高于对数据维护性能要求时，应该尽量使用索引，否则，就要慎重考虑一下付出的代价。在某些极端情况下，可先删除索引，再对数据库表更新大量数据，最后再重建索引，新建立的索引总是比较好用。

 

原文： http://hi.baidu.com/mayw1985/item/11b268ad8af7612e030a4da3

 

SQLSERVER2008R2正确使用索引

T1表 10000000万条数据,（插入时间36分钟，count(*)查询19秒，空间占用670M左右）

 

1.真正充分的利用索引
比如like '张%' 就是符合SARG(符合扫描参数)标准
而like '%张' 就不符合该标准

通配符%在字符串首字符的使用会导致索引无法使用，虽然实际应用中很难避免这样用，但还是应该对这种现象有所了解，至少知道此种用法性能是很低下的。

 

**********************************************

2.“非”操作符不满足SARG形式，使得索引无法使用
不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等。
如果使用not 或者 <>,最好转换成别的方法，比如例子如下：

T1表 10000000万条数据,构建如下:（插入时间36分钟，count(*)查询19秒，空间占用670M左右）

DECLARE @i INT
SET @i = 1
WHILE @i<1000000
BEGIN
 INSERT INTO t1 VALUES ('zhang'+CONVERT(char(50), @i),'3.2',77);
 SET @i + 1;
END

三种查询方式：

SELECT * FROM t1 WHERE id <>300000
SELECT * FROM t1 WHERE id NOT IN (300000)
SELECT * FROM t1 WHERE id >299999 AND id < 300001

在执行计划中可以明显看出，使用最后一种方式而不是前面两种方式进行查询。
网上是这么说的，但自己做的试验100W条数据，开销计划是一样的。

 

*********************************************

 

3. 函数运算不满足SARG形式，使得索引无法使用
例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：

select * from record where substring(card_no,1,4)=′5378′(13秒)
select * from record where amount/30< 1000（11秒）
select * from record where convert(char(10),date,112)=′19991201′（10秒）

分析：

where子句中对列的任何操作结果都是在SQL运行时逐列计算得到的，因此它不得不进行全表扫描，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被SQL优化器优化，使用索引，避免表搜索，因此将SQL重写成下面这样：

select * from record where card_no like ′5378%′（< 1秒）
select * from record where amount < 1000*30（< 1秒）
select * from record where date= ′1999/12/01′ （< 1秒）

你会发现SQL明显快很多

待测试.......

 

**********************************************

 

4.尽量不要对建立了索引的字段，作任何的直接处理

select * from employs where first_name + last_name ='beill cliton';

无法使用索引，改为：

select * from employee where
first_name = substr('beill cliton',1,instr('beill cliton',' ')-1)
and
last_name = substr('beill cliton',instr('beill cliton',' ')+1)

则可以使用索引

***********************************************

5.不同类型的索引效能是不一样的，应尽可能先使用效能高的
比如：数字类型的索引查找效率高于字符串类型，定长字符串char，nchar的索引效率高于变长字符串varchar,nvarchar的索引。
应该将
where username='张三' and age>20
改进为
where age>20 and username='张三'
注意：此处，SQL的查询分析优化功能可以做到自动重排条件顺序，但还是建议预先手工排列好。

**************************************************

6.某些情况下IN 的作用与OR 相当 ，且都不能充分利用索引
例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL：
select count(*) from stuff where id_no in(′0′,′1′) （23秒）
我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用id_no上的索引；但实际上,它却采用了"OR策略"，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用id_no 上索引，并且完成时间还要受tempdb数据库性能的影响。
实践证明，表的行数越多，工作表的性能就越差，当stuff有620000行时，执行时间会非常长！如果确定不同的条件不会产生大量重复值，还不如将or子句分开：

select count(*) from stuff where id_no=′0′
select count(*) from stuff where id_no=′1′

得到两个结果，再用union作一次加法合算。因为每句都使用了索引，执行时间会比较短，

select count(*) from stuff where id_no=′0′
union
select count(*) from stuff where id_no=′1′

从实践效果来看，使用union在通常情况下比用or的效率要高的多，而exist关键字和in关键字在用法上类似，性能上也类似，都会产生全表扫描，效率比较低下，根据未经验证的说法，exist可能比in要快些。

***************************************************

7.使用变通的方法提高查询效率

　　like关键字支持通配符匹配，但这种匹配特别耗时。例如：select * from customer where zipcode like “21_ _ _”，即使在zipcode字段上已建立了索引，在这种情况下也可能还是采用全表扫描方式。如果把语句改为：select * from customer where zipcode >“21000”，在执行查询时就会利用索引，大大提高速度。但这种变通是有限制的，不应引起业务意义上的损失，对于邮政编码而言，zipcode like “21_ _ _” 和 zipcode >“21000” 意义是完全一致的。

*********************************************************人各有志,但富贵在天，人生允许彷徨,但不允许蹉跎.

 

8.order by按聚集索引列排序效率最高
排序是较耗时的操作，应尽量简化或避免对大型表进行排序，如缩小排序的列的范围，只在有索引的列上排序等等。
我们来看：（gid是主键，fariqi是聚合索引列）
select top 10000 gid,fariqi,reader,title from tgongwen
用时：196 毫秒。 扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc
用时：4720毫秒。 扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc
用时：4736毫秒。 扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc
用时：173毫秒。 扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc
用时：156毫秒。 扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。

同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。

 

********************************************************

9.关于节省数据查询系统开销方面的措施
 (1)使用TOP尽量减少取出的数据量
 (2)字段提取要按照“需多少、提多少”的原则，避免“select *”
字段大小越大，数目越多，select所耗费的资源就越多，比如取int类型的字段就会比取char的快很多。我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的幅度根据舍弃的字段的大小来判断
 (3)count(*) 与 count(字段) 方法比较
 用count(*)和用 count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总速度就越慢。如果用 count(*)， SQL SERVER会自动查找最小字段来汇总。当然，如果您直接写count(主键)将会来的更直接些
 (4)有嵌套查询时，尽可能在内层过滤掉数据
 如果一个列同时在主查询和where子句中出现，很可能当主查询中的列值改变之后，子查询必须重新查询一次。而且查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行
 (5)多表关联查询时，需注意表顺序，并尽可能早的过滤掉数据
 在使用Join进行多表关联查询时候，应该使用系统开销最小的方案。连接条件要充份考虑带有索引的表、行数多的表，并注意优化表顺序；说的简单一点，就是尽可能早的将之后要做关联的数据量降下来。

 一般情况下，sqlserver 会对表的连接作出自动优化。例如：
 select name,no from A
 join B on A. id=B.id
 join C on C.id=A.id
 where name='wang'
        尽管A表在From中先列出，然后才是B,最后才是C。但sql server可能会首先使用c表。它的选择原则是相对于该查询限制为单行或少数几行，就可以减少在其他表中查找的总数据量。绝大多数情况下，sql server 会作出最优的选择，但如果你发觉某个复杂的联结查询速度比预计的要慢，就可以使用SET FORCEPLAN语句强制sql server按照表出现顺序使用表。如上例加上：SET FORCEPLAN ON…….SET FORCEPLAN OFF 表的执行顺序将会按照你所写的顺序执行。在查询分析器中查看2种执行效率，从而选择表的连接顺序。SET FORCEPLAN的缺点是只能在存储过程中使用

 

 

PS:数据库的查询优化技术 
 
数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。 
笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。 

分析问题 

许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面重点说明改善用户查询计划的解决方案。  
解决问题 
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。 

1．合理使用索引 
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下： 
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。 
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。 
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。 
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。 
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。 

2．避免或简化排序 
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素： 
●索引中不包括一个或几个待排序的列； 
●group by或order by子句中列的次序与索引的次序不一样； 
●排序的列来自不同的表。 
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。 

3．消除对大型表行数据的顺序存取 
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。 
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作： 
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008 
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句： 
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001 
UNION 
SELECT ＊ FROM orders WHERE order_num=1008 
这样就能利用索引路径处理查询。 

4．避免相关子查询 
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。 

5．避免困难的正规表达式 
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _” 
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。 
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询 
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如： 
SELECT cust.name，rcvbles.balance，……other columns 
FROM cust，rcvbles 
WHERE cust.customer_id = rcvlbes.customer_id 
AND rcvblls.balance>0 
AND cust.postcode>“98000” 
ORDER BY cust.name 
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序： 
SELECT cust.name，rcvbles.balance，……other columns 
FROM cust，rcvbles 
WHERE cust.customer_id = rcvlbes.customer_id 
AND rcvblls.balance>0 
ORDER BY cust.name 
INTO TEMP cust_with_balance 
然后以下面的方式在临时表中查询： 
SELECT ＊ FROM cust_with_balance 
WHERE postcode>“98000” 
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。 
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。 

7．用排序来取代非顺序存取 
非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。 
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。