很多朋友可能都做过数据库优化，或者感觉自己做过数据库优化。实际上可能是帮着研发人员优化过几条SQL，或者加个索引啥的。说是做优化，也算，不过这种融入于日常工作中的优化工作与真正的优化项目还是有很大差别的。前几天我和一个客户交流他们的SQL SERVER系统优化的问题。他说他们以前一直在做优化，碎片整理、历史数据清理、索引重建、SQL优化等。不过随着业务规模提升，这些优化工作的效果越来越差。他想启动一个全面 优化项目，找到问题真正的原因，能够尽可能多地解决掉这些问题，这样在2027年系统切换国产数据库之前，能确保稳定运行。
这个情况和我的《Oracle DBA优化日记》里的场景有些相似。当时一些DBA都质疑我所说的这个优化项目是否真实存在，因为似乎优化的限制条件多了些。比如硬件无法扩容和更新，开发商能力不足，业务负载爆发式增长等，这些前置条件在现实中是否存在。实际上这是一个十分真实的案例，当年参与这个案例的当事人有些已经退休。案例是发生在2005年左右，用户是辽宁电信。当时辽宁电信还是一个级别比较低的电信公司，属于北方电信的一个下属机构。因为当时规划中要将北方电信的数据中心合并，因此在那个时间段里冻结了系统升级改造，只能通过整体优化来维持三年左右的稳定运行。
目前的情况与20年前十分相似，很多系统在2027年底前可能就面临要更换为国产化设备了，因此这些年扩容和改造系统的投资肯定是会受到限制的。采用成本相对较低的数据库优化可能是保持当前系统稳定运行，应对近期业务增长的一种比较好的方法，在系统优化工作中，类似DBA优化日记中的场景可能也会再次出现。
不同的DBA所经历过的优化工作都会有所不同，这是因为他们面对的客户的优化需求是不同的。有些用户就是几条烂SQL引发了问题，那么解决掉这几条SQL的问题就没啥可优化的事情做了。这种情况投入较大的资金去全面优化，其实是没有什么必要的。我想大多数DBA以前面对的优化项目可能大多如此，这也是我们在讨论优化的时候，很多DBA觉得能做SQL优化才是DBA最牛叉的技能。随着AI技术的发展，我倒是觉得SQL优化是最容易被AI替代的技能，其门槛会快速降低。因为SQL优化的规则相对固定，用例也广泛存在，比较容易获取。前阵子遇到一条PG的SQL性能问题，执行计划有八九十行，不想看，就直接扔给kimi了，没想到KIMI的回答十分靠谱，依托KIMI的建议，我花了5分钟就把问题找到了。
大家也不用被KIMI的能力吓到了，虽然在SQL优化领域AI有着强大的潜力，不过优化依然是一个离不开专家的工作。面对一个复杂的系统的时候，SQL优化可能只能解决一些表面的问题，通过降低系统的负载和开销来达到优化的目的永远是可行的，但是也存在一个问题 ，那就是只解决了表层问题，并没有解决底层问题。如果数据库的配置存在不合理的配置项，那么这个配置项将会在数据库的某种负载或者并发达到某个极限的时候爆发，出现故障。如果数据库底层的操作系统存在一个对于某种数据库不合理的配置参数，也会产生类似的瓶颈。数据库的底层硬件存在某个不合理的瓶颈，网络参数存在某个不合理的配置，都可以在某种负载下出现 不稳定或者性能下降，这些问题往往隐藏得很深，不做全面优化分析都很难找出来。
前些天我的一个客户的PG数据库FREEEZE了，只能进入单用户状态去做VACUUM FREEZE，否则数据库都起不来了。事后我把我以前写过的一篇文章发给他，让他们根据文章要求去优化一下参数。他们觉得很奇怪，都搞定了，为啥还要去优化参数。我说如果不优化参数，下回还会出事。他们照着去做了，然后说以后是不是可以高枕无忧了。我说不行，因为这是PG的一个巨大的缺陷，优化了参数当前可能不会出问题了，但是说不准在某些特定情况下还是会出问题。因此需要针对FREEZE情况做日常监控，最好做个监控项和月度巡检项，随时关注这个问题。出问题前提前处置，就不至于像这回一样，搞出一个停机几个小时的故障了。
这种运维运营工作上的优化也是优化的一种形式，优化的目的是保障业务连续性和客户体验，因此优化其实是个综合性的问题。对于绝大多数DBA参与过的优化工作而言，都好像是盲人摸象一样，可能只是摸到了优化工作的一条腿或者一只耳朵而已。
