优化--让你的SQL运行速度明显提高-转http://pcedu.pconline.com.cn/empolder/db/other/0506/640941
人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结：（为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过１秒的均表示为（< 1秒）。 ）
一、不合理的索引设计 例：表record有620000行，试看在不同的索引下，下面几个 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数据库性能的影响。 实践证明，表的行数越多ぷ鞅淼男阅芫驮讲睿眘tuff有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