[原] JT SQL Server 性能调优札记之四
2009-02-20 13:18
375 查看
真凶
谨慎起见,我并没有马上将索引应用到生产的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。定时执行清空这个表的数据。
相关文章推荐
- [原] JT SQL Server 性能调优札记之一
- [原] JT SQL Server 性能调优札记之二
- [原] JT SQL Server 性能调优札记之三
- SQL Server DBA 必须了解的性能调优要点
- Oracle 性能调优之:使用 V$SQL_PLAN 视图查询内存中的执行计划
- SQLSERVER SQL性能优化
- SQL 2016 性能调优培训来了!!! 还免费!!!
- [转]SQL2005]安装Ms SQL Server 2005 开发版时出现性能计数器要求安装错误的解决办法
- Oracle sql 调优:使用虚拟索引在生产环境测试创建索引对数据库性能的影响
- HBCZT信息中心Weblogic Server性能调优建议
- SQL 性能调优日常积累
- 基于性能的设计和sql调优培训的总结
- Oracle Sql 语句性能调优
- .Net+SQL Server企业应用性能优化笔记4——精确查找瓶颈
- SQL Server 性能调优札记
- SQL优化(SQL TUNING)之10分钟完毕亿级数据量性能优化(SQL调优)
- SQLSERVER SQL性能优化
- Spark SQL概念学习系列之性能调优
- SQL-SERVER 性能查询死锁、堵塞
- SQL Server性能调优之执行计划深度剖析 第一节 浅析SQL执行的过程