论数据库系统调优的必要性

论数据库系统调优的必要性

在为很多大客户的数据库系统调优工作中，虽然这些客户的系统都都配备了非常专业的DBA（或者聘请了业界知名的第三方维护团队），但是查出来的性能问题还是触目惊心（第一次优化时，查看了优化报告才知道问题有多严重，系统还有那么多的优化空间），可想而知其他中小客户的数据库系统面临的是一个什么情况。

“系统慢不是问题，只要不崩溃就行”，可能这是大多数DBA的想法。

在日常使用过程中，你的数据库系统经常出一些故障（硬件问题除外，不过如果磁盘经常坏，应该也和性能有关），很多时候就是因为：没有使用绑定变量、错误的设置了一些优化器参数、并发过大、缺少索引（最普遍）、统计信息不准确、SQL写法不佳、RAC系统按照单节点设计等等一系列性能问题，而导致系统压力过大而出现的状况。

但是好多人宁愿出故障时救火，却不愿意花时间去优化数据库。试想如果你的系统经过全面优化，负载很小，还会经常出各种问题吗？

100%的数据库都是可以优化的，CPU降低，资源争用小，系统就会更加稳定；IO压力降低，SQL执行速度加快，磁盘寿命也会更长。

现在的普遍问题是：

大部分DBA对数据库调优还只停留在优化效果非常小的参数调整上（除非遇到严重错误的参数设置），甚至经常出现因为改了一些参数导致性能更差。AWR 报告更是基本不看。还有一些水平高一些的DBA，认为自己管理的库已经没啥好优化的，实际上还是问题一大堆。

好的DBA应该能发现SQL性能问题，将问题反馈给研发，更高一个层次的还会将如何改进告诉研发人员。

而研发人员基本上为了实现功能就已经焦头烂额了，如果SQL执行的不是非常慢，根本不会考虑其性能问题，只有在效率实在无法接受时，才会想尽各种办法（分步、分区、分表、并发）让业务得以在要求的时间内完成。

还有个比较现实的问题：

一些经验丰富的开发人员大部分都变成了管理人员，代码经常是由一些缺少经验的程序员写出来的，如果没有接受相关的培训，写出来的SQL性能可想而知。不同的SQL写法，效率也是有很多差别的，这些套路如果不掌握，SQL不但慢，而且是资源杀手。

由此导致很多客户遇到系统压力大时，直接想到的是更换高级别的服务器和存储，但其实很多数据库系统只要进行性能调优，即可带来的性能提升可以达到几百上千倍，这是也是换任何高级服务器和存储都无法实现的。

其实以上所说的，都只是想让大家（主要是DBA和研发人员，基本上很少有领导关注这种纯技术的公众号）知道数据库系统调优的必要性，如果你愿意做个优秀的消防员表现给领导看，或者希望为拉动GDP多做贡献，那么可以忽略上面我说的话。