MSSQL调优实战一 乱建聚集索引的后果

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

但在优化的时候有个问题觉得很奇怪:
4000万的数据,查找其中的2万条,根据日期上的过滤,我想应该是一个嵌套的书签查询计划,结果看到MSSQL给出的答案却是聚集索引扫描。4000万比2万的数据,却宁愿表扫描而不愿意做嵌套?只有指定了使用非聚集索引后查询计划才改成嵌套的书签查询。
问问大家这个是为何呢?难道聚集索引扫描的IO更低?

你可能感兴趣的:(MSSQL调优实战一 乱建聚集索引的后果)