关于数据库优化的一些感想和建议

今天不写优化，说点感想和建议（昨天就要发的，结果第一次用手机操作，发错了，只发出去一张网上找的美图）：

在oracle做研发和售后这么多年，为很多大客户的数据库做了优化，这些客户的系统都是非常重要的系统，而且都配备了非常专业的DBA（或者聘请了业界知名的第三方维护团队），但是查出来的性能问题还是触目惊心（第一次优化前都是抱着试试看的态度，看了优化报告才知道问题有多严重，系统还有那么多的优化空间），可想而知其他中小客户的系统面临的是一个什么情况。

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

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

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

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

现在的普遍问题是：

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

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

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

还有个比较现实的问题：

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

很多客户遇到系统压力大，首先想到的是更换高级别的服务器和存储（很多单个SQL的优化带来的性能提升可以达到几百上千倍，这是换任何高级服务器和存储都无法实现的），或者是考虑分表、分库，这些办法需要耗费大量的人力和财力（当然对拉动GDP很有帮助）。其实大部分情况下做个优化就好了。

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