很多好友或许都做过数据库优化，或许觉得自己做过数据库优化。实践上或许是帮着研发人员优化过几条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介入过的优化上班而言，都如同是盲人摸象一样，或许只是摸到了优化上班的一条腿或许一只耳朵而已。