很多朋友可能都做過數據庫優化，或者感覺自己做過數據庫優化。實際上可能是幫著研發人員優化過幾條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參與過的優化工作而言，都好像是盲人摸象一樣，可能只是摸到了優化工作的一條腿或者一只耳朵而已。