今天下午优化了一个存储过程，通过sys.dm_exec_query_stats和sys.dm_exec_sql_text() 定位到的，发现运行次数虽然很少，但是每次却长达上千万毫秒的cpu消耗，但实际执行虽然时间比较久，却也不过几十分钟而已，不知道是不是SQLServer系统性能视图的缺陷。既然有问题那就找吧这是一个存储过程，类似于create procedure sp_exec_taskasdeclare cursor cur_test for select * from tableAbeginopen cur_testfetch cur_test into ...WHILE @@FETCH_STATUS=0 BEGIN if true update tableB where id=tableA.id and other_cond else update tableB where id=tableA.id and other_cond if true update tableC where id=tableA.id and other_cond else update tableC where id=tableA.id and other_cond fetch cur_test into ...endCLOSE cur_testDEALLOCATE cur_testend怎么分析呢？1、开始的时候是让游标空循环，发现一共1万多条记录，空循环时间基本为02、再次把所有的DML语句转化为SELECT，并记录每个步骤的运行时间和一次完整游标的循环时间最后循环中变为BEGIN print 'step 1'+convert(varchar,109,getdate() select * from tableB where id=tableA.id and other_cond print 'step 1'+convert(varchar,109,getdate() select * from tableC where id=tableA.id and other_condEND通过上百次的循环测试，发现每次循环大概需要60毫秒，100次的花就是6秒，10000次可不就是10分钟3、检查了一下游标循环中用的表和where条件，发现选择性不错，就添加索引，再次安装上面的办法进行测试这次是单次循环0~1毫秒，100次大概是1秒，10000次还是需要1分多钟的4、1分多钟是可以忍受的，干脆直接测完吧，运行过程中，不断发现内存消耗极大，很快居然耗光了内存5、添加了SET NOCOUNT ON之类的，运行后还是内存暴增6、后来思考了一下是不是select * from tableB的不断刷新导致的，直接修改为 select top 1 @tt=tt from tableB where id=tableA.id and other_cond这样就不会持续刷新屏幕了7、运行后，果然只需要短短的4秒钟。总结：其实在数据库中与性能相关的，无论是耗cpu还是耗内存还是耗硬盘还是锁的问题，分析到最后，95%以上都与SQL和索引相关首先要找到问题，才能谈到分析问题，分析问题就在于多实践，而实践在于尽量屏蔽与问题无关的外界因素。
本文转自baoqiangwang51CTO博客，原文链接：http://blog.51cto.com/baoqiangwang/355716，如需转载请自行联系原作者
