注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

网事

备忘录

 
 
 

日志

 
 

SQL优化 索引(二)  

2009-11-09 12:54:24|  分类: sql server |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
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这个关键词。

  到此为止,我们上面讨论了如何实现从大容量的数据库中快速地查询出您所需要的数据方法。当然,我们介绍的这些方法都是“软”方法,在实践中,我们还要考虑各种“硬”因素,如:网络性能、服务器的性能、操作系统的性能,甚至网卡、交换机等。

  评论这张
 
阅读(141)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018