ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SQL Server调优实战 乱建聚集索引的后果

SQL Server调优实战 乱建聚集索引的后果

原创 Linux操作系统 作者:iSQlServer 时间:2009-04-20 15:01:14 0 删除 编辑
今天调优某电信的大型数据库,是一个日志型的表,其中有个自增列字段和时间(时间是每个小时小时来的,每个小时有大概23万条记录),以及点击次数等日志信息,数据量在4000万以上,sp_spaceused使用了大概2G多的磁盘空间。整个表没有分区。整个表都是插入查询,没有更新操作。

  有一个基于时间字段上的时间段where范围选择,然后聚合找到某些类型的聚合值

  观察发现自增列字段就是一个摆设,没有任何作用,也不做任何表的外键,只是可能当时开发人员在设计表的时候就不管3721都来一个自增列主键,导致在对date字段上的非聚集索引扫描后,还需要去聚集索引树上seek一下,这下子就增加一个嵌套查询了。去掉表上的主键聚集索引,将表回归为堆,这样在非聚集索引扫描后直接就拿到RID找相应行了。

  后来又想办法整了个date字段上的include索引,将要汇总的字段都加到非聚集索引上来,连RID查找都不要了。include虽然增加磁盘开销,但是速度上去很多,且没有针对索引的更新,不涉及索引拆分等费时操作,所以觉得还是值得。

  最后优化结果,由45秒到20秒。

  优化结果还比较满意,最后最重要的是因为IO始终将不下来,因为数据太多了。

  不知道还有没有办法能想想的。

  其实以前自己在设计数据库的时候也经常对表开始就来一个主键,而并没有考虑其实际意义,导致表的操作非常困难。

  这个日志类型的表基本不需要自增主键字段,他不会根据某一日志ID范围来查找或者更新日志。

  但在优化的时候有个问题觉得很奇怪:

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

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16436858/viewspace-591030/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-10-17

  • 博文量
    1319
  • 访问量
    2080755