转载：http://hi.baidu.com/yfdong21/blog/item/3acebe8980023fbd0f244401.html
一、什么情况下适合建立索引？
每个表只能有一个聚集索引
关联字段上应该建立索引
在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引
多条件查询时，联合索引效率较高。
经常同时存取多列，且每列都含有重复值可考虑建立组合索引
书签查找的原因是使用了SELECT *。由于在绝大多情况下它会返回比你实际所需更多的数据，所以应该
永不使用SELECT *.
二、什么情况下会使用索引查询？
1、Like语句是否属于SARG取决于使用%通配符的样式，通配符%在字符串首字符的使用会导致索引无法使用。
例如：name like ‘张%’ ，这就属于SARG,而：name like ‘%张’ ,就不属于SARG
2、 “非”操作符不满足SARG形式，使得索引无法使用。
不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等。
例如：select * from employee where salary<>3000;
select * from employee where salary<3000 or salary>3000;
第二种查询允许对salary列使用索引，而第一种查询则不能使用索引。
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秒）
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、 尽量不要使用 is null 与 is not null作为查询条件
任何包含null值的列都将不会被包含在索引中，如果某列数据中存在空值，那么对该列建立索引的性能提升是值得怀疑的，
尤其是将null作为查询条件的一部分时。建议一方面避免使用is null和is not null, 另一方面不要让数据库字段中存在null, 即使没有内容，也应利用缺省值，或者手动的填入一个值，如:’’ 空字符串。
7、 某些情况下IN 的作用与OR 相当 ，且都不能充分利用索引
例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL：
select count(*) from stuff where id_no in(′0′,′1′) （23秒）
where条件中的′in′在逻辑上相当于′or′，所以语法分析器会将in (′0′,′1′)转化为id_no =′0′ or id_no=′1′来执行。
我们期望它会根据每个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要快些。
8、 使用变通的方法提高查询效率
like关键字支持通配符匹配，但这种匹配特别耗时。例如：select * from customer where zipcode like “21_ _ _”，
即使在zipcode字段上已建立了索引，在这种情况下也可能还是采用全表扫描方式。
如果把语句改为：select * from customer where zipcode >“21000”，在执行查询时就会利用索引，大大提高速度。
但这种变通是有限制的，不应引起业务意义上的损失，对于邮政编码而言，zipcode like “21_ _ _” 和 zipcode >“21000” 意义是完全一致的。
9、 组合索引的高效使用
假设已在date，place，amount三个字段上建立了组合索引
select count(*) from record where date > ′19991201′ and date < ′19991214′ and amount > 2000 (< 1秒)
select date,sum(amount) from record group by date （11秒）
select count(*) from record where date > ′19990901′ and place in (′BJ′,′SH′)（< 1秒）
这是一个设置较合理的组合索引。它将date作为前导列，使每个SQL都可以利用索引，并且在第一和第三个SQL中形成了索引覆盖，因而性能达到了最优。如果索引不便于更改，修正SQL中的条件顺序以配合索引顺序也是可行的。
10、 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 次。
从以上我们可以看出，不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的，但这些都比“order by 非聚集索引列”的查询速度是快得多的。
同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。
三、索引的使用规则
联合索引使用总结:
1、查询条件中出现联合索引第一列,或者全部,则能利用联合索引.
2、条件列中只要条件相连在一起,以本文例子来说就是:
3、查询条件中没有出现联合索引的第一列,而出现联合索引的第二列,或者第三列,都不会利用联合索引查询.
单一列索引的应用总结:
1、只要条件列中出现索引列,无论在什么位置,都能利用索引查询.
两者的共同点:
1、要想利用索引,都要符合SARG标准.
2、都是为了提高查询速度.
3、都需要额外的系统开销,磁盘空间.
两者的区别：
1、索引所占用空间:单一列索引相对要小.
2、索引创建时间:单一列索引相对短.
3、索引对insert,update,delete的影响程序:单一列索引要相对低.
4、在多条件查询时,联合索引效率要高.
四、关于节省数据查询系统开销方面的措施
1、 使用TOP尽量减少取出的数据量，TOP是SQL SERVER中用来提取前几条或前某个百分比数据的关键词。
select top 20 gid,fariqi,reader,title from tgongwen order by gid desc
select top 60 percent gid,fariqi,reader,title from tgongwen order by gid desc
在实际的应用中，应该经常利用top 剔除掉不必要的数据，只保留必须的数据集合。这样不仅可以减少数据库逻辑读的次数，还能避免不必要的内存浪费，对系统性能的提升都是有好处的。
2、 字段提取要按照“需多少、提多少”的原则，避免“select *”
例：
select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc 用时：4673毫秒
select top 10000 gid,fariqi,title from tgongwen order by gid desc 用时：1376毫秒
select top 10000 gid,fariqi from tgongwen order by gid desc 用时：80毫秒
由此看来，字段大小越大，数目越多，select所耗费的资源就越多，比如取int类型的字段就会比取char的快很多。我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的幅度根据舍弃的字段的大小来判断。
3、 count(*) 与 count(字段) 方法比较
我们来看一些实验例子（gid为Tgongwen的主键）：
select count(*) from Tgongwen 用时：1500毫秒
select count(gid) from Tgongwen 用时：1483毫秒
select count(fariqi) from Tgongwen 用时：3140毫秒
select count(title) from Tgongwen 用时：52050毫秒
从以上可以看出，用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的缺点是只能在存储过程中使用。
- 聚集索引比较宝贵，应该用在查询频率最高的地方；
- 在数据为“既不是绝大多数相同，也不是极少数相同”状态时，最能发挥聚集索引的潜力。
- 复合索引的设置和使用要注意保持顺序一致；
- 条件子句的表达式最好符合SARG规范，是可利用索引的；
- 任何对列的操作都导致全表扫描，如数据库函数、计算表达式等，
- 查询时应尽可能将操作移至等号的某一边；
- 要注意含有null值时，是不能充分利用索引的；
- exist, in、or等子句常会使索引失效；
- 如果不产生大量重复值，可以考虑把子句拆开，再用union拼合；
- 排序时应充分利用带索引的字段；
- 尽可能早，快的过滤掉无用的数据，只将必须的数据带到后续的操作中去