真凶

谨慎起见，我并没有马上将索引应用到生产的JT数据库上面，晚上12点，再次登陆数据库服务器，查看以下CPU的负载，把我吓了一跳。负载还是那么高，按我们的经验晚上该数据库服务应该是非常空闲的，为什么还会有这么大的负载呢。

马上打开活动监视器，发现结果还是和以前的一样，还是jt_user的用户CPU和IO最高，但是晚上jt_user对应的应用系统应该没有人用。

马上打开SQL Profiler，事件仅选BatchCompleted，将CPU的阀值设为5，Duration的阀值设为10，这个阀值其实已经很低的了，也就晚上12点我才敢这么设定。

结果收集的结果吓我一跳，

在短短的13分钟内，竟然同一条语句执行了1479次。

select top 1 end_time from Log_Network_circs order by end_time desc

Log_Network_circs这张表有2657563条记录，平均每秒查询1.89次，每分钟查询113.8次，说白了就是秒对一个265万条记录的表进行排序。而且这条语句明显能写成：

select max(end_time) from Log_Network_circs

又短效率比原来的还高，想不明白。以下是统计信息。

表 'Log_Network_circs'。扫描计数 3，逻辑读取 16352 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

SQL Server 执行时间:
   CPU 时间 = 1156 毫秒，占用时间 = 619 毫秒。

更要命的是，我发现这个表的记录数是时刻增长的，每秒4~5条。insert 语句肯定肯定是让我那个这么低的阀值过滤掉了。

这个明显属于应用系统设计的问题，找开发商聊了。

不是办法的办法

与开发商联系后，问清楚情况，确认该表的数据可以删除，以防万一，将数据库备份，然后truncate了这个表。但是这个不是一个最好的解决办法，我个人认为该问题应该在应用层上面解决。我向开发商提出了以下几点建议：

1。将查询的频率调低一点。
2。select max(end_time) from Log_Network_circs 能比原来这条语句性能好很多，如果只是为了查最后一条。
3。直接写个触发器，在插入的时候把end_time存到别的表里面去，然后在这个表里面取end_time的值。
4。定时执行清空这个表的数据。