开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5） 新人奖直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
这个题目将会延续9周，这是第二期关于性能优化的误区，性能优化是数据库中重要的工作，老书中对于性能优化中的问题给出了全面系统的范例，今天我们就来读一读，将正确和错误的观点梳理一遍。
在重新读了这两页文字后，尤其在在调借参数的部分，可以深入，当前很多初级的一些 DBA 人员或非 DBA 人员，对于参数的调节和调优十分有兴趣，并钻研和埋头其中，认为挑战完参数后，数据库的性能都会有一个性能的飞跃。
实际上不是这样的，我曾经也深入其中，甚至有很多的国产数据库的企业，雇佣专门的参数调优的人员来负责，壳数据库和硬件的之间的匹配，认为这就是数据库调优的终极奥义。
书中有明确的提示，参数调优是必要条件，但不是充分条件。同时不合理的参数调节会要命的，而且数据库系统的参数调优是需要一个长期的过程，尤其对于POSTGRESQL 这样的数据库，或以POSTGRESQL 作为基础二开的数据库产品。有一些参数在调节后，是在针对某些硬件范围的基础上，比如你的硬件的资源并不完全赋予，但充足的时候，可以调节，产生效果，而部分情况下，由于硬件本身的缺失，在调节参数也是事倍功半。
书中的第二个小结，关于数据库的优化就是DBA 的工作者部分，我是深有体会的。 在之前单位招聘DBA的过程中，曾经有一个DBA 让我记忆深刻，30多岁，对于当前的工作的国有企业深恶痛绝，这里主要让我记忆的有两个点
1 他的领导一个办公室主任什么都不懂
2 他的领导一直强调，数据库的工作以及责任在他，需要他尽心竭力的优化
事情是，这个ORACLE 的DBA 工作的企业是国有性质，他的顶头上司并不是IT 出身，对于数据库更是一窍不通，并且国有企业的系统大多是购买和采购，或乙方开发的，问题就出在这里，这些系统里面存在大量的编写语句不合理的情况，虽然添加了索引，但对于有些SQL 和 程序的编制还是存在不合理和无法解决的问题，而他的领导一直强调是 他的工作不力导致的系统的性能不优，而对他进行责难。时间长了，就产生了怨念和不想在这个国企工作的想法和动作。
但我这里也劝这位同学，虽然有怨气，但你除了是一个DBA 你也是一个职场人，所以在沟通和工作方法上，你还有很多路要走。
书中后面的是三个部分都是与开发和SQL语句有关的，说实在的数据库作为背锅侠，也是常事，尤其在一些资历较浅的DBA 存在的工作，基于DBA只是重复性，硬件性，和参数性的工作，对于数据库承接的更大的盘子根本无法掌握，或者根本不想理解或了解，导致最终所有的问题在萌芽期无法进行干预和解决，最终导致数据库称为压垮系统性能和最后一个稻草。
比如程序架构没有考虑，系统的高负载的压力承受的情况，将所有的系统的写到一个数据库里面，这就导致后期数据库的压力问题，只能数据库自己承担，而无法通过分库来解决，不同库 或不同 schema 中的表都是通过数据库底层来进行访问的，没有通过程序解决，这就导致后期也无法通过分库来解决性能的问题，而导致积重难返的情况。
另外还有一部分同学对于SQL 的撰写也是一字一句的校对，这也有些过分，数据库作为一个数据存储和处理的容器，必然要包容，那些由于某些数据库性能不佳而遗留的 毒害，不应该是群体数据库来承担。
比如MYSQL 的数据处理能力差的问题，这不是所有数据库的锅，众多的数据库的数据处理能力都优于 MYSQL 这是毫无疑问的。所以不要上来 就拿着MYSQL的 军规，或什么 阿里的法旨 来去教导所有的项目和数据库上的程序设计。
最终数据库的优化是一个综合性，网状的思维和优化道路，找到系统最弱的点去优化才是有意义的，而不是朝着一个老鼠洞挖个不停。
