今天调优某电信的大型数据库，是一个日志型的表，其中有个自增列字段和时间（时间是每个小时小时来的，每个小时有大概23万条记录），以及点击次数等日志信息，数据量在4000万以上，sp_spaceused使用了大概2G多的磁盘空间。整个表没有分区。整个表都是插入查询，没有更新操作。
#h;~9T6m-t0e程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛        　%s(u-@.K2I3j%O![
        　　有一个基于时间字段上的时间段where范围选择，然后聚合找到某些类型的聚合值。
0?.i5I6F:e1T        　$}-_7O4k3X E,B'@
        　　观察发现自增列字段就是一个摆设，没有任何作用，也不做任何表的外键，只是可能当时开发人员在设计表的时候就不管3721都来一个自增列主键，导致在对date字段上的非聚集索引扫描后，还需要去聚集索引树上seek一下，这下子就增加一个嵌套查询了。去掉表上的主键聚集索引，将表回归为堆，这样在非聚集索引扫描后直接就拿到RID找相应行了。
/j,E)N%d$j1u;f(P程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛        　
'['c7?0V2Xtech.techweb.com.cn        　　后来又想办法整了个date字段上的include索引，将要汇总的字段都加到非聚集索引上来，连RID查找都不要了。include虽然增加磁盘开销，但是速度上去很多，且没有针对索引的更新，不涉及索引拆分等费时操作，所以觉得还是值得。
*t+T;T({6w!a        　#z8h!o4m1Z0L#T$T5m)T
        　　最后优化结果，由45秒到20秒。
3i1i,T.N*w$z&W7?5~        　
3w#D"r$k9k(l"t*a:DTechWeb-技术社区        　　优化结果还比较满意，最后最重要的是因为IO始终将不下来，因为数据太多了。
9|+j7e$}%U)E9s$Etech.techweb.com.cn        　&N6|!X(D9g-[4\
        　　不知道还有没有办法能想想的。程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛7f*Q;x&d(B4k2s
        　
+o9F.Z)Y3?5p$m;O;`:~TechWeb-技术社区        　　其实以前自己在设计数据库的时候也经常对表开始就来一个主键，而并没有考虑其实际意义，导致表的操作非常困难。程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛(o%C$o8P)k'J7U
        　程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛/o&N:d#f R"P&V;x-T z,v
        　　这个日志类型的表基本不需要自增主键字段，他不会根据某一日志ID范围来查找或者更新日志。程序开发，操作系统，服务器，源码下载，Linux,Unix,BSD,PHP,Apach,asp,下载,源码,黑客,安全,技术社区,技术论坛%r-E"u5N S2x
        　
!j+o&t;Y$w5~7z6W        　　但在优化的时候有个问题觉得很奇怪：TechWeb-技术社区9l T6X9e;}(u

-[6Z*E:E9x;d/|$_            4000万的数据，查找其中的2万条，根据日期上的过滤，我想应该是一个嵌套的书签查询计划，结果看到MSSQL给出的答案却是聚集索引扫描。4000万比2万的数据，却宁愿表扫描而不愿意做嵌套？只有指定了使用非聚集索引后查询计划才改成嵌套的书签查询。