[原] JT SQL Server 性能调优札记之四

真凶

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

image_thumb_4

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

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

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

image

在短短的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。定时执行清空这个表的数据。

posted @ 2009-02-20 13:18  killkill  阅读(3399)  评论(23编辑  收藏  举报