SQL Server中的SQL语句优化与效率问题
很多人不知道SQL语句在SQLSERVER中是如何执行的，他们担心自己所写的SQL语句会被SQLSERVER误解。比如：
select*fromtable1wherename='zhangsan'andtID>10000
和执行:
select*fromtable1wheretID>10000andname='zhangsan'
一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。
事实上，这样的担心是不必要的。SQLSERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。
虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。
在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。
SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：
列名操作符<常数或变量>
或
<常数或变量>操作符列名列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：
Name='张三'
价格>5000
5000<价格
Name='张三'and价格>5000
如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQLSERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。
介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：
1、Like语句是否属于SARG取决于所使用的通配符的类型
--如：
namelike'张%'--，这就属于SARG
--而：
namelike'%张'--,就不属于SARG。
原因是通配符%在字符串的开通使得索引无法使用。
2、or会引起全表扫描
Name='张三'and价格>5000符号SARG，而：Name='张三'or价格>5000则不符合SARG。使用or会引起全表扫描。
3、非操作符、函数引起的不满足SARG形式的语句
不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOTEXISTS、NOTIN、NOTLIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：
ABS(价格)<5000
Namelike'%三'
--有些表达式，如：
WHERE价格*2>5000
--SQLSERVER也会认为是SARG，SQLSERVER会将此式转化为：
WHERE价格>2500/2
但我们不推荐这样使用，因为有时SQLSERVER不能保证这种转化与原始表达式是完全等价的。
4、IN的作用相当与OR
语句：
Select*fromtable1wheretidin(2,3)
--和
Select*fromtable1wheretid=2ortid=3
是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。
5、尽量少用NOT
6、exists和in的执行效率是一样的
很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用notexists来代替notin。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQLSERVER自带的pubs数据库。运行前我们可以把SQLSERVER的statisticsI/O状态打开：
（1）
selecttitle,pricefromtitleswheretitle_idin(selecttitle_idfromsaleswhereqty>30)
该句的执行结果为：
表'sales'。扫描计数18，逻辑读56次，物理读0次，预读0次。
表'titles'。扫描计数1，逻辑读2次，物理读0次，预读0次。
（2）
selecttitle,pricefromtitles
whereexists(select*fromsales
wheresales.title_id=titles.title_idandqty>30)
第二句的执行结果为：
表'sales'。扫描计数18，逻辑读56次，物理读0次，预读0次。
表'titles'。扫描计数1，逻辑读2次，物理读0次，预读0次。
我们从此可以看到用exists和用in的执行效率是一样的。
7、用函数charindex()和前面加通配符%的LIKE执行效率一样
前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：
selectgid,title,fariqi,readerfromtgongwen
wherecharindex('刑侦支队',reader)>0andfariqi>'2004-5-5'
用时：7秒，另外：扫描计数4，逻辑读7155次，物理读0次，预读0次。
selectgid,title,fariqi,readerfromtgongwen
wherereaderlike'%'+'刑侦支队'+'%'andfariqi>'2004-5-5'
用时：7秒，另外：扫描计数4，逻辑读7155次，物理读0次，预读0次。
8、union并不绝对比or的执行效率高
我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwen
wherefariqi='2004-9-16'orgid>9990000
用时：68秒。扫描计数1，逻辑读404008次，物理读283次，预读392163次。
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi='2004-9-16'
union
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwheregid>9990000
用时：9秒。扫描计数8，逻辑读67489次，物理读216次，预读7499次。
看来，用union在通常情况下比用or的效率要高的多。
但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwen
wherefariqi='2004-9-16'orfariqi='2004-2-5'
用时：6423毫秒。扫描计数2，逻辑读14726次，物理读1次，预读7176次。
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi='2004-9-16'
union
selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi='2004-2-5'
用时：11640毫秒。扫描计数8，逻辑读14806次，物理读108次，预读1144次。
9、字段提取要按照“需多少、提多少”的原则，避免“select*”
我们来做一个试验：
selecttop10000gid,fariqi,reader,titlefromtgongwenorderbygiddesc
用时：4673毫秒
selecttop10000gid,fariqi,titlefromtgongwenorderbygiddesc
用时：1376毫秒
selecttop10000gid,fariqifromtgongwenorderbygiddesc
用时：80毫秒
由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。
10、count(*)不比count(字段)慢
某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：
selectcount(*)fromTgongwen
用时：1500毫秒
selectcount(gid)fromTgongwen
用时：1483毫秒
selectcount(fariqi)fromTgongwen
用时：3140毫秒
selectcount(title)fromTgongwen
用时：52050毫秒
从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。我想，如果用count(*)，SQLSERVER可能会自动查找最小字段来汇总的。当然，如果您直接写count(主键)将会来的更直接些。
11、orderby按聚集索引列排序效率最高
我们来看：（gid是主键，fariqi是聚合索引列）：
selecttop10000gid,fariqi,reader,titlefromtgongwen
用时：196毫秒。扫描计数1，逻辑读289次，物理读1次，预读1527次。
selecttop10000gid,fariqi,reader,titlefromtgongwenorderbygidasc
用时：4720毫秒。扫描计数1，逻辑读41956次，物理读0次，预读1287次。
selecttop10000gid,fariqi,reader,titlefromtgongwenorderbygiddesc
用时：4736毫秒。扫描计数1，逻辑读55350次，物理读10次，预读775次。
selecttop10000gid,fariqi,reader,titlefromtgongwenorderbyfariqiasc
用时：173毫秒。扫描计数1，逻辑读290次，物理读0次，预读0次。
selecttop10000gid,fariqi,reader,titlefromtgongwenorderbyfariqidesc
用时：156毫秒。扫描计数1，逻辑读289次，物理读0次，预读0次。
从以上我们可以看出，不排序的速度以及逻辑读次数都是和“orderby聚集索引列”的速度是相当的，但这些都比“orderby非聚集索引列”的查询速度是快得多的。
同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。
12、高效的TOP
事实上，在查询和提取超大容量的数据集时，影响数据库响应时间的最大因素不是数据查找，而是物理的I/0操作。如：
selecttop10*from(
selecttop10000gid,fariqi,titlefromtgongwen
whereneibuyonghu='办公室'
orderbygiddesc)asa
orderbygidasc
这条语句，从理论上讲，整条语句的执行时间应该比子句的执行时间长，但事实相反。因为，子句执行后返回的是10000条记录，而整条语句仅返回10条语句，所以影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQLSERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现TOP确实很好用，效率也很高。但这个词在另外一个大型数据库ORACLE中却没有，这不能说不是一个遗憾，虽然在ORACLE中可以用其他方法（如：rownumber）来解决。在以后的关于“实现千万级数据的分页显示存储过程”的讨论中，我们就将用到TOP这个关键词。
到此为止，我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然，我们介绍的这些方法都是“软”方法，在实践中，我们还要考虑各种“硬”因素，如：网络性能、服务器的性能、操作系统的性能，甚至网卡、交换机等。