根据设计惯例,查询的时候主子表通过关键词字段关联查询,查询语句如下: select top 1000 a.word,a.queryurl,a.irank,a.title,a.baiduurl,a.itraffic1,a.itraffic2,b.ibaiduindex from zibiao a with(nolock) inner join zhubiao b with(nolock) on a.word=
根据设计惯例,查询的时候主子表通过关键词字段关联查询,查询语句如下:
select top 1000 a.word,a.queryurl,a.irank,a.title,a.baiduurl,a.itraffic1,a.itraffic2,b.ibaiduindex from zibiao a
with(nolock)
inner join zhubiao b with(nolock) on a.word=b.word
where a.queryurl='http://zhidao.baidu.com'
order by b.ibaiduindex desc,a.irank
发现速度很慢,快的时候瞬间,慢的时候长达几分钟。分析sql server的查询执行计划如下:
分析这个执行计划图,主要资源开销是在主表的聚集索引查找,应该是子表根据网址找到关键词后,再到主表中查找关键词对应的指数的这一步比较耗时。
因这2个表的更新频率非常高,以为是更新频率太快,导致索引效率降低,于是想到用数据库读写分离的方案,专门拿了一台备用服务器,通过发布订阅的方法 ,将这两张表发布到备用服务器上,专门在备用服务器上做查询,发现速度并没有得到提升。
在csdn上发了一个讨论帖,网友讨论很热烈,sql server的很多版主都有参与讨论,给出的方案也很多。有人说是IO读写瓶颈,于是升级了下服务器,硬盘采用raid10的固态硬盘,内存更是升级到了128G,不过效果仍旧不明显,同样的语句,慢的时候还是需要几十秒。
有网友给出的方案,是建议把主表字段放到子表冗余,以减少关联的资源消耗,再结合以上的执行计划图,确实瓶颈是在主表的的聚集索引查找上,于是单独执行了下子表的irank排序语句:
select top 1000 a.word,a.queryurl,a.irank,a.title,a.baiduurl,a.itraffic1,a.itraffic2 from zibiao a
with(nolock)
where a.queryurl='http://zhidao.baidu.com'
order by a.irank
发现执行速度非常快,几乎秒开了,当然irank字段上有建索引的。
测试成功,于是将主表的ibaiduindex字段放到子表冗余,并且建立好索引(这里的索引建立是有技巧的)。执行语句:
select top 1000 a.word,a.queryurl,a.irank,a.title,a.baiduurl,a.itraffic1,a.itraffic2,a.ibaiduindex from zibiao a
with(nolock)
where a.queryurl='http://zhidao.baidu.com'
order by a.ibaiduindex desc,a.irank
查询瞬间出来结果。执行计划如下:
这里拿以上这个sql语句来分析,我们该如何建立索引。索引建立包括字段的先后顺序,字段的排序方法,include项都很重要,任何一个弄错,都不能达到好的优化效果。
1.我们肯定需要建立一个组合索引。那么应该组合字段用哪几个呢?这里我的组合字段是:queryurl(这个字段第一, 因为我们最先是根据这个字段进行筛选的)、ibaiduindex、irank
2.这里要注意下,因为我的固定排序就是ibaiduindex desc,irank asc,所以字段的排列顺序应该是:queryurl,ibaiduindex,irank。同时排序的类别是:ibaiduindex desc ,irank asc。这里我一开始没注意,ibaiduindex的排序是asc,结果发现执行上面那个SQL语句仍然需要2秒。
3.索引包含项,也很重要,如果不用包含项,索引查找到主键后, 还要根据主键去查找其他字段。所以我们需要设置索引包含性列,,把除掉索引字段中剩余的其他字段都加进去。
优化后的效果就如上面的执行计划图所示,一次非聚集索引查找,就找到我们的数据,而且都不需要排序耗时,因为我们的索引已经按照顺序排列好了。当然,这里要说明下,索引包含确实好用,但是代价就是磁盘的空间。加了索引包含项,数据库空间增加了几十个G。
本文原创发布php中文网,转载请注明出处,感谢您的尊重!