SQL Server调优实战


今天调优某电信的大型数据库,是一个日志型的表,其中有个自增列字段和时间(时间是每个小时小时来的,每个小时有大概23万条记录),以及点击次数等日志信息,数据量在4000万以上,sp_spaceused使用了大概2G多的磁盘空间。整个表没有分区。整个表都是插入查询,没有更新操作。


 
  有一个基于时间字段上的时间段where范围选择,然后聚合找到某些类型的聚合值。
 
  观察发现自增列字段就是一个摆设,没有任何作用,也不做任何表的外键,只是可能当时开发人员在设计表的时候就不管3721都来一个自增列主键,导致在对date字段上的非聚集索引扫描后,还需要去聚集索引树上seek一下,这下子就增加一个嵌套查询了。去掉表上的主键聚集索引,将表回归为堆,这样在非聚集索引扫描后直接就拿到RID找相应行了。
 
  后来又想办法整了个date字段上的include索引,将要汇总的字段都加到非聚集索引上来,连RID查找都不要了。include虽然增加磁盘开销,但是速度上去很多,且没有针对索引的更新,不涉及索引拆分等费时操作,所以觉得还是值得。
 
  最后优化结果,由45秒到20秒。
 
  优化结果还比较满意,最后最重要的是因为IO始终将不下来,因为数据太多了。
 
  不知道还有没有办法能想想的。
 
  其实以前自己在设计数据库的时候也经常对表开始就来一个主键,而并没有考虑其实际意义,导致表的操作非常困难。
 
  这个日志类型的表基本不需要自增主键字段,他不会根据某一日志ID范围来查找或者更新日志。
 
  但在优化的时候有个问题觉得很奇怪:

     4000万的数据,查找其中的2万条,根据日期上的过滤,我想应该是一个嵌套的书签查询计划,结果看到MSSQL给出的答案却是聚集索引扫描。4000万比2万的数据,却宁愿表扫描而不愿意做嵌套?只有指定了使用非聚集索引后查询计划才改成嵌套的书签查询

本文作者:
« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3