2、改善SQL语句
　　很多人不知道SQL语句在SQL SERVER中是如何执行他们担心自己所写SQL语句会被SQL SERVER误解比如:
select * from table1 where name=’zhangsan’ and tID > 10000
　　和执行:
select * from table1 where tID > 10000 and name=’zhangsan’
　　些人不知道以上两条语句执行效率是否样如果简单从语句先后上看这两个语句确是不样如果tID是个聚合索引那么后句仅仅从表10000条以后记录中查找就行了；而前句则要先从全表中查找看有几个name=’zhangsan’而后再根据限制条件条件tID>10000来提出查询结果
　　事实上这样担心是不必要SQL SERVER中有个“查询分析优化器”它可以计算出where子句中搜索条件并确定哪个索引能缩小表扫描搜索空间也就是说它能实现自动优化
　　虽然查询优化器可以根据where子句自动进行查询优化但大家仍然有必要了解下“查询优化器”工作原理如非这样有时查询优化器就会不按照您本意进行快速查询
　　在查询分析阶段查询优化器查看查询每个阶段并决定限制需要扫描数据量是否有用如果个阶段可以被用作个扫描参数(SARG)那么就称的为可优化并且可以利用索引快速获得所需数据
　　SARG定义:用于限制搜索个操作它通常是指个特定匹配个值得范围内匹配或者两个以上条件AND连接形式如下:
列名 操作符 <常数 或 变量>
或
<常数 或 变量> 操作符列名
　　列名可以出现在操作符边而常数或变量出现在操作符另边如:
Name='张 3'
价格>5000
5000<价格
Name='张 3' and 价格>5000
　　如果个表达式不能满足SARG形式那它就无法限制搜索范围了也就是SQL SERVER必须对每行都判断它是否满足WHERE子句中所有条件所以个索引对于不满足SARG形式表达式来说是无用
　　介绍完SARG后我们来整理总结下使用SARG以及在实战中遇到和某些资料上结论区别经验:
　　1、Like语句是否属于SARG取决于所使用通配符类型
　　如:name like ‘张%' 这就属于SARG
　　而:name like ‘%张' ,就不属于SARG
　　原因是通配符%在串开通使得索引无法使用
　　2、or 会引起全表扫描
Name='张 3' and 价格>5000 符号SARG而:Name='张 3' or 价格>5000 则不符合SARG使用or会引起全表扫描
　　3、非操作符、引起不满足SARG形式语句
　　不满足SARG形式语句最典型情况就是包括非操作符语句如:NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等另外还有下面就是几个不满足SARG形式例子:
ABS(价格)<5000
Name like ‘% 3'
　　有些表达式如:
WHERE 价格*2>5000
　　SQL SERVER也会认为是SARGSQL SERVER会将此式转化为:
WHERE 价格>2500/2
　　但我们不推荐这样使用有时SQL SERVER不能保证这种转化和原始表达式是完全等价
　　4、IN 作用相当和OR
　　语句:
Select * from table1 where tid in (2,3)
　　和
Select * from table1 where tid=2 or tid=3
　　是样都会引起全表扫描如果tid上有索引其索引也会失效
　　5、尽量少用NOT
　　6、exists 和 in 执行效率是样
　　很多资料上都显示说exists要比in执行效率要高同时应尽可能用not exists来代替not in但事实上我试验了下发现 2者无论是前面带不带not 2者的间执行效率都是样涉及子查询我们试验这次用SQL SERVER自带pubs数据库运行前我们可以把SQL SERVERstatistics I/O状态打开
　　(1)select title,price from titles where title_id in (select title_id from sales where qty>30)
　　该句执行结果为:
　　表 ’sales’扫描计数 18逻辑读 56 次物理读 0 次预读 0 次
　　表 ’titles’扫描计数 1逻辑读 2 次物理读 0 次预读 0 次
　　(2)select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)
　　第 2句执行结果为:
　　表 ’sales’扫描计数 18逻辑读 56 次物理读 0 次预读 0 次
　　表 ’titles’扫描计数 1逻辑读 2 次物理读 0 次预读 0 次
　　我们从此可以看到用exists和用in执行效率是样
　　7、用charindex和前面加通配符%LIKE执行效率样
　　前面我们谈到如果在LIKE前面加上通配符%那么将会引起全表扫描所以其执行效率是低下但有资料介绍说用charindex来代替LIKE速度会有大提升经我试验发现这种介绍说明也是:
select gid,title,fariqi,reader from tgongwen where charindex(’刑侦支队’,reader)>0 and fariqi>’2004-5-5’
　　用时:7秒另外:扫描计数 4逻辑读 7155 次物理读 0 次预读 0 次
select gid,title,fariqi,reader from tgongwen where reader like ’%’ + ’刑侦支队’ + ’%’ and fariqi>’2004-5-5’
　　用时:7秒另外:扫描计数 4逻辑读 7155 次物理读 0 次预读 0 次
　　8、union并不绝对比or执行效率高
　　我们前面已经谈到了在where子句中使用or会引起全表扫描般我所见过资料都是推荐这里用union来代替or事实证明这种说法对于大部分都是适用
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’ or gid>9990000
　　用时:68秒扫描计数 1逻辑读 404008 次物理读 283 次预读 392163 次
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’
union
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000
　　用时:9秒扫描计数 8逻辑读 67489 次物理读 216 次预读 7499 次
　　看来用union在通常情况下比用or效率要高多
　　但经过试验笔者发现如果or两边查询列是样话那么用union则反倒和用or执行速度差很多虽然这里union扫描是索引而or扫描是全表
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’ or fariqi=’2004-2-5’
　　用时:6423毫秒扫描计数 2逻辑读 14726 次物理读 1 次预读 7176 次
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’
union
select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-2-5’
　　用时:11640毫秒扫描计数 8逻辑读 14806 次物理读 108 次预读 1144 次
　　9、字段提取要按照“需多少、提多少”原则避免“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毫秒
　　由此看来我们每少提取个字段数据提取速度就会有相应提升提升速度还要看您舍弃字段大小来判断
　　10、count(*)不比count(字段)慢
　　某些资料上说:用*会统计所有列显然要比个世界列名效率低这种说法其实是没有根据我们来看:
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(主键)将会来更直接些
　　11、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 非聚集索引列”查询速度是快得多
　　同时按照某个字段进行排序时候无论是正序还是倒序速度是基本相当
　　12、高效TOP
　　事实上在查询和提取超大容量数据集时影响数据库响应时间最大原因不是数据查找而是物理I/0操作如:
select top 10 * from (
select top 10000 gid,fariqi,title from tgongwen
where neibuyonghu=’办公室’
order by gid desc) as a
order by gid asc
　　这条语句从理论上讲整条语句执行时间应该比子句执行时间长但事实相反子句执行后返回是10000条记录而整条语句仅返回10条语句所以影响数据库响应时间最大原因是物理I/O操作而限制物理I/O操作此处最有效思路方法的就是使用TOP关键词了TOP关键词是SQL SERVER中经过系统优化过个用来提取前几条或前几个百分比数据词经笔者在实战中应用发现TOP确实很好用效率也很高但这个词在另外个大型数据库ORACLE中却没有这不能说不是个遗憾虽然在ORACLE中可以用其他思路方法(如:rownumber)来解决在以后有关“实现千万级数据分页显示存储过程”讨论中我们就将用到TOP这个关键词
　　到此为止我们上面讨论了如何实现从大容量数据库中快速地查询出您所需要数据思路方法当然我们介绍这些思路方法都是“软”思路方法在实战中我们还要考虑各种“硬”原因如:网络性能、服务器性能、操作系统性能甚至网卡、交换机等