系统慢得一批？看数据库运维老司机如何做优化

数据库内部运行因素：从各种指标来分析，系统语句等待时间太长，导致语句完成慢，而等待主要有两部分：

• 硬件资源确实有压力;
• 语句之前的阻塞太严重了，"LCK_M_"，而且等待时间过长，竟然平均达到几百秒。

再分析...这么强的硬件，并不大的访问压力，竟然造成瓶颈?语句写的烂?程序实现的不好?缺索引?环境配置不对?

下面我们来看看....

优化阶段一(常规优化)

很多时候系统慢要究其原因，难道上线时候就这么慢?那不可能，厂商根本无法交付的!那么问题来了，系统是什么时候开始慢的?对系统做过哪些调整?

简单的调研，出击!

我靠!!!厂商完全不配合，工程师对系统及其不熟悉，一问三不知，最近做什么改动也说不清，用户也不知道。厂商给的结论：继续加硬件，更强的IO，数据分离减小数据量……

协调厂商完全协调不动，基本没戏了。

既然是数据库问题，那我们就数据库下手吧!从一名数据库从业人员的角度来说，看到这样的系统一定要先解决大面积等待问题。个人经验来看很多系统大面积等待解决系统会有个很大的提升和改善。

配合一些常规的调优手段，阶段一开始了。主要给系统大面积创建影响高开销大的索引，调整系统参数，优化tempDB等....具体不细说了，前面系列文章中都有。

预期：

一般系统上面一轮优化会有明显的改善，我认为这一轮以后系统会明显变快，语句运行环境合适，索引什么的合理资源消耗自然就少，内存和IO压力也会有所减少。

结果：

系统内存，IO压力趋于平稳，慢语句数量有所减少，但依然很多，阻塞依然存在，超过2分钟的语句依然很多。

优化前：

优化后

优化前

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!