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

再次临时表的写入量太大，千万级别数据同步也是问题，这里好就好在程序中写入的物理临时表都是以“Temp_” 开头并以GUID类型结尾。我们在这里设置了只要这样的表写入不会反向同步给主节点，这样根据规则控制双向同步满足了报表的要求，最终实现了报表的分离。

报表快了? 当然没有，只是分离不可能快，但是好处有三个：

OLAP和OLTP分离事务阻塞得到解决;

报表服务器和业务服务器可以根据自身的业务特别进行单独的个性化设置;

根据报表的要求我们配置高速IO的硬件。

预期：

语句已经优化，阻塞情况也被解决，CPU、内存、磁盘压力也没有了，系统肯定快起来了!

结果：

系统快起来了!

最终业务系统节点全天24小时的慢语句数量：

(虽然还有慢语句存在，毕竟是TB级别的数据量，不影响业务运行客户完全可以接受。)

总结

系统慢往往我们要全面分析，本文提供的维度：

• 业务压力
• 硬件
• 环境
• 代码
• 数据库内部运行因素
• 架构

往往优化真的不是简单的调一调语句，加一加硬件，全面地分析是根本解决性能问题的首要任务。

当然不是所有的优化都可以彻底解决，如本文中报表的改善是通过读写分离的方式实现，很多时候在ERP系统中报表的处理方式都是如此，报表如果细致优化，那需要多长时间呀!也许都是重写了。

本文的优化过程主要是：

全面分析系统问题 → 宏观层面解决(环境、数据库内部运行因素、硬件压力) → 低效代码调整 → 架构方案实现(稳定、安全、高效) → 最终系统顺畅无压力。

（编辑：衡阳站长网）

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