2、不充份的链接条件：性能优化
例：表card有7896行，在card_no上有一个非汇集索引，表account有191122行，在 account_no上有一个非汇集索引，试看在不一样的表链接条件下，两个SQL的执行状况：网络
select sum(a.amount) from account a， card b where a.card_no = b.card_no |
（20秒）ide
将SQL改成：函数
select sum(a.amount) from account a， card b where a.card_no = b.card_no and a. account_no=b.account_no |
（< 1秒）性能
分析：优化
在第一个链接条件下，最佳查询方案是将account做外层表，card做内层表，利用card上的索引，其I/O次数可由如下公式估算为：google
外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/Ourl
在第二个链接条件下，最佳查询方案是将card做外层表，account做内层表，利用account上的索引，其I/O次数可由如下公式估算为：
外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O
可见，只有充份的链接条件，真正的最佳方案才会被执行。
总结：
1.多表操做在被实际执行前，查询优化器会根据链接条件，列出几组可能的链接方案并从中找出系统开销最小的最佳方案。链接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数肯定，乘积最小为最佳方案。
2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就能够看到链接顺序、使用何种索引的信息；想看更详细的信息，需用sa角色执行dbcc(3604，310，302)。
3、不可优化的where子句
1.例：下列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明显快起来！
2.例：表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上的索引；但实际上（根据showplan），它却采用了"OR策略"，即先取出知足每一个or子句的行，存入临时数据库的工做表中，再创建惟一索引以去掉重复行，最后从这个临时表中计算结果。所以，实际过程没有利用id_no上索引，而且完成时间还要受tempdb数据库性能的影响。
实践证实，表的行数越多，工做表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分开：
select count(*) from stuff where id_no='0' select count(*) from stuff where id_no='1' |
获得两个结果，再做一次加法合算。由于每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。或者，用更好的方法，写一个简单的存储过程：
create proc count_stuff as declare @a int declare @b int declare @c int declare @d char(10) begin select @a=count(*) from stuff where id_no='0' select @b=count(*) from stuff where id_no='1' end select @c=@a+@b select @d=convert(char(10)，@c) print @d |
直接算出结果，执行时间同上面同样快！
总结：
可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。
1.任何对列的操做都将致使表扫描，它包括数据库函数、计算表达式等等，查询时要尽量将操做移至等号右边。
2.in、or子句常会使用工做表，使索引失效；若是不产生大量重复值，能够考虑把子句拆开；拆开的子句中应该包含索引。
3.要善于使用存储过程，它使SQL变得更加灵活和高效。
从以上这些例子能够看出，SQL优化的实质就是在结果正确的前提下，用优化器能够识别的语句，充份利用索引，减小表扫描的I/O次数，尽可能避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深刻研究还会涉及数据库层的资源配置、网络层的流量控制以及操做系统层的整体设计。