|
此文章由 典 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 典 所有!转贴必须注明作者、出处和本声明,并保持内容完整
几个月前陆陆续续做了一个主要数据库的调优,写出来给自己留个记号(已经忘记掉很多了),也希望对初学者有参考意义。
这个MS SQL2000数据库越来越慢,主要原因是每年在系统上加应用模块,而且业务数据不断增加。主要的表现有两个:在外地的200多销售人员在Sync数据的时候长达5-10分钟,每天都有好多DeadLock。 而且有一种越来越差的发展趋势。
我们这里没有专职的SQLDBA,我只好自己上马,用了一部分时间做了些调优,取得了不错的效果,现在Sync的时间大部分都在30秒内,很少有DeadLock,几个月过去了高枕无忧。
1. 数据库硬件升级,买了一个很好的服务器,使用64位系统(原来是32位),40多G内存,windows2008 / SQL Enterprise 2008
2 Index优化, 对几个大的表调整了index,调整后效果非常明显,使用statistics比较就知道,一个同样的查询,从SCAN几十万降到scan几千。调的时候仔细阅读代码,从代码中发现蛛丝蚂迹, where 或者join on所需要的index 比较好找,select 后面隐含的index需求比较难点。 主要的工具就是execution plan
3 优化修改了一批stored proc, 尤其是有些代码带有很多子查询,仔细阅读后发现了一些不合理的地方,进行改写并比较statistics,效果明显;一些无法避免的大查询,在业务许可的时候加入readuncommitted hint,避免lock
4 稍微修改了一下系统,
4.1 一些比较静态的查询(比如过去几个月客户们的销售历史),在半夜的时候用job建立临时表,并给临时表分配index,这样查起来飞快,效果很明显;
4.2 一些计算:需要用到大量join或子查询,直接改到客户端去做计算,有好几个这样的成功例子。其中有一个网页查询,每次需要延迟10几秒才能有结果,用户非常不爽,经过分析后我用C#给写了一段代码,把计算逻辑放到网页内部去完成,结果用户感觉不到任何延迟(延迟低于1秒),
4.3 差不多同上,干脆把一些中间计算结果保存到数据表中,其它地方需要的时候就不用算来算去,直接取出来
5.有些比较新的技术对执行效率并没有好处,比如Common Table Expression - CTE, 我做了很多statistics比较,效率并没有任何提高,只是使代码读起来非常简洁而已
本来还有几个慢的stored proc程序,已经准备了优化方案,考虑到方方面面的用户已经对系统很满意了,所以暂时不管了。 |
评分
-
查看全部评分
|