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