：（一）深入浅出理解索引结构.htm

平时搜集的数据库操作文档

      Tgongwen order by fariqi<BR><BR>用时：12936<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen order by 
      gid<BR><BR>用时：18843<BR><BR>这里，用聚合索引比用一般的主键作order 
      by时，速度快了3/10。事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。<BR><BR>3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi&gt;'2004-1-1'<BR><BR>用时：6343毫秒（提取100万条） <BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi&gt;'2004-6-6'<BR><BR>用时：3170毫秒（提取50万条）<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi='2004-9-16'<BR><BR>用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi&gt;'2004-1-1' and fariqi&lt;'2004-6-6'<BR><BR>用时：3280毫秒<BR><BR>4 
      、日期列不会因为有分秒的输入而减慢查询速度<BR><BR>下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精确到日；之前有数据50万条，有5000个不同的日期，日期精确到秒。<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi&gt;'2004-1-1' order by fariqi<BR><BR>用时：6390毫秒<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi&lt;'2004-1-1' order by 
      fariqi<BR><BR>用时：6453毫秒<BR><BR>（五）其他注意事项<BR><BR>“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。<BR><BR>所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。<BR><BR>当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。<BR><BR><BR><BR>二、改善SQL语句<BR><BR>很多人不知道SQL语句在SQL 
      SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：<BR><BR>select * from table1 
      where name='zhangsan' and tID &gt; 10000<BR><BR>和执行:<BR><BR>select * from 
      table1 where tID &gt; 10000 and 
      name='zhangsan'<BR><BR>一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID&gt;10000来提出查询结果。<BR><BR>事实上，这样的担心是不必要的。SQL 
      SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。<BR><BR>虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。<BR><BR>在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。<BR><BR>SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：<BR><BR>列名 
      操作符 &lt;常数 或 变量&gt;<BR><BR>或<BR><BR>&lt;常数 或 变量&gt; 
      操作符列名<BR><BR>列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：<BR><BR>Name=’张三’<BR><BR>价格&gt;5000<BR><BR>5000&lt;价格<BR><BR>Name=’张三’ 
      and 价格&gt;5000<BR><BR>如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL 
      SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。<BR><BR>介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：<BR><BR>1、Like语句是否属于SARG取决于所使用的通配符的类型<BR><BR>如：name 
      like ‘张%’ ，这就属于SARG<BR><BR>而：name like ‘%张’ 
      ,就不属于SARG。<BR><BR>原因是通配符%在字符串的开通使得索引无法使用。<BR><BR>2、or 
      会引起全表扫描<BR><BR>Name=’张三’ and 价格&gt;5000 符号SARG，而：Name=’张三’ or 价格&gt;5000 
      则不符合SARG。使用or会引起全表扫描。<BR><BR>3、非操作符、函数引起的不满足SARG形式的语句<BR><BR>不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、&lt;&gt;、!&lt;、!&gt;、NOT 
      EXISTS、NOT IN、NOT 
      LIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：<BR><BR>ABS(价格)&lt;5000<BR><BR>Name like 
      ‘%三’<BR><BR>有些表达式，如：<BR><BR>WHERE 价格*2&gt;5000<BR><BR>SQL 
      SERVER也会认为是SARG，SQL SERVER会将此式转化为：<BR><BR>WHERE 
      价格&gt;2500/2<BR><BR>但我们不推荐这样使用，因为有时SQL 
      SERVER不能保证这种转化与原始表达式是完全等价的。<BR><BR>4、IN 的作用相当与OR<BR><BR>语句：<BR><BR>Select 
      * from table1 where tid in (2,3)<BR><BR>和<BR><BR>Select * from table1 
      where tid=2 or 
      tid=3<BR><BR>是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。<BR><BR>5、尽量少用NOT<BR><BR>6、exists 
      和 in 的执行效率是一样的<BR><BR>很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not 
      in。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQL 
      SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。<BR><BR>（1）select 
      title,price from titles where title_id in (select title_id from sales 
      where qty&gt;30)<BR><BR>该句的执行结果为：<BR><BR>表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 
      次，预读 0 次。<BR><BR>表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 
      次。<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;<BR><BR>（2）select title,price from 
      titles where exists (select * from sales where 
      sales.title_id=titles.title_id and qty&gt;30)<BR><BR>第二句的执行结果为：<BR><BR>表 
      'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。<BR><BR>表 'titles'。扫描计数 1，逻辑读 2 
      次，物理读 0 次，预读 0 
      次。<BR><BR>我们从此可以看到用exists和用in的执行效率是一样的。<BR><BR>7、用函数charindex()和前面加通配符%的LIKE执行效率一样<BR><BR>前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：<BR><BR>select 
      gid,title,fariqi,reader from tgongwen where charindex('刑侦支队',reader)&gt;0 
      and fariqi&gt;'2004-5-5'<BR><BR>用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 
      次。<BR><BR>select gid,title,fariqi,reader from tgongwen where reader like 
      '%' + '刑侦支队' + '%' and fariqi&gt;'2004-5-5'<BR><BR>用时：7秒，另外：扫描计数 4，逻辑读 
      7155 次，物理读 0 次，预读 0 
      次。<BR><BR>8、union并不绝对比or的执行效率高<BR><BR>我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' 
      or gid&gt;9990000<BR><BR>用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 
      次。<BR><BR>select gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi='2004-9-16' <BR><BR>union<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      gid&gt;9990000<BR><BR>用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 
      次。<BR><BR>看来，用union在通常情况下比用or的效率要高的多。<BR><BR>但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' 
      or fariqi='2004-2-5'<BR><BR>用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 
      次。<BR><BR>select gid,fariqi,neibuyonghu,reader,title from Tgongwen where 
      fariqi='2004-9-16' <BR><BR>union<BR><BR>select 
      gid,fariqi,neibuyonghu,reader,title from Tgongwen 
      where&nbsp;&nbsp;fariqi='2004-2-5'<BR><BR>用时：11640毫秒。扫描计数 8，逻辑读 14806 
      次，物理读 108 次，预读 1144 次。<BR><BR>9、字段提取要按照“需多少、提多少”的原则，避免“select 
      *”<BR><BR>我们来做一个试验：<BR><BR>select top 10000 gid,fariqi,reader,title from 
      tgongwen order by gid desc<BR><BR>用时：4673毫秒<BR><BR>select top 10000 
      gid,fariqi,title from tgongwen order by gid 
      desc<BR><BR>用时：1376毫秒<BR><BR>select top 10000 gid,fariqi from tgongwen 
      order by gid 
      desc<BR><BR>用时：80毫秒<BR><BR>由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。<BR><BR>10、count(*)不比count(字段)慢<BR><BR>某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：<BR><BR>select 
      count(*) from Tgongwen<BR><BR>用时：1500毫秒<BR><BR>select count(gid) from 
      Tgongwen <BR><BR>用时：1483毫秒<BR><BR>select count(fariqi) from 
      Tgongwen<BR><BR>用时：3140毫秒<BR><BR>select count(title) from 
      Tgongwen<BR><BR>用时：52050毫秒<BR><BR>从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。我想，如果用count(*)， 
      SQL SERVER可能会自动查找最小字段来汇总的。当然，如果您直接写count(主键)将会来的更直接些。<BR><BR>11、order 
      by按聚集索引列排序效率最高<BR><BR>我们来看：（gid是主键，fariqi是聚合索引列）<BR><BR>select top 10000 
      gid,fariqi,reader,title from tgongwen<BR><BR>用时：196 毫秒。 扫描计数 1，逻辑读 289 
      次，物理读 1 次，预读 1527 次。<BR><BR>select top 10000 gid,fariqi,reader,title from 
      tgongwen order by gid asc<BR><BR>用时：4720毫秒。 扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 
      1287 次。<BR><BR>select top 10000 gid,fariqi,reader,title from tgongwen 
      order by gid desc<BR><BR>用时：4736毫秒。 扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 
      次。<BR><BR>select top 10000 gid,fariqi,reader,title from tgongwen order by 
      fariqi asc<BR><BR>用时：173毫秒。 扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。<BR><BR>select 
      top 10000 gid,fariqi,reader,title from tgongwen order by fariqi 
      desc<BR><BR>用时：156毫秒。 扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0