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

《关于数据库优化的一些感想和建议》要点：
本文介绍了关于数据库优化的一些感想和建议，希望对您有用。如果有疑问，可以联系我们。

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

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

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

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

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

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

现在的普遍问题是：

大部分DBA对数据库的优化还只停留在参数调整上,而参数调整能带来的优化效果一般是非常小的(除非遇到严重错误的参数设置),而且经常因为改了一些参数导致性能更差.AWR报告更是基本不看.还有一些水平高一些的DBA,认为自己管理的库已经没啥好优化的,实际上还是问题一大堆.
好的DBA应该能发现SQL性能问题,将问题反馈给研发,更高一个层次的还会将如何改进告诉研发人员.

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

还有个比较现实的问题：

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

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

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

原文来自：老虎刘谈SQL优化