很多朋友可能都做過(guò)數(shù)據(jù)庫(kù)優(yōu)化，或者感覺(jué)自己做過(guò)數(shù)據(jù)庫(kù)優(yōu)化。實(shí)際上可能是幫著研發(fā)人員優(yōu)化過(guò)幾條SQL，或者加個(gè)索引啥的。說(shuō)是做優(yōu)化，也算，不過(guò)這種融入于日常工作中的優(yōu)化工作與真正的優(yōu)化項(xiàng)目還是有很大差別的。前幾天我和一個(gè)客戶(hù)交流他們的SQL SERVER系統(tǒng)優(yōu)化的問(wèn)題。他說(shuō)他們以前一直在做優(yōu)化，碎片整理、歷史數(shù)據(jù)清理、索引重建、SQL優(yōu)化等。不過(guò)隨著業(yè)務(wù)規(guī)模提升，這些優(yōu)化工作的效果越來(lái)越差。他想啟動(dòng)一個(gè)全面 優(yōu)化項(xiàng)目，找到問(wèn)題真正的原因，能夠盡可能多地解決掉這些問(wèn)題，這樣在2027年系統(tǒng)切換國(guó)產(chǎn)數(shù)據(jù)庫(kù)之前，能確保穩(wěn)定運(yùn)行。

這個(gè)情況和我的《Oracle DBA優(yōu)化日記》里的場(chǎng)景有些相似。當(dāng)時(shí)一些DBA都質(zhì)疑我所說(shuō)的這個(gè)優(yōu)化項(xiàng)目是否真實(shí)存在，因?yàn)樗坪鮾?yōu)化的限制條件多了些。比如硬件無(wú)法擴(kuò)容和更新，開(kāi)發(fā)商能力不足，業(yè)務(wù)負(fù)載爆發(fā)式增長(zhǎng)等，這些前置條件在現(xiàn)實(shí)中是否存在。實(shí)際上這是一個(gè)十分真實(shí)的案例，當(dāng)年參與這個(gè)案例的當(dāng)事人有些已經(jīng)退休。案例是發(fā)生在2005年左右，用戶(hù)是遼寧電信。當(dāng)時(shí)遼寧電信還是一個(gè)級(jí)別比較低的電信公司，屬于北方電信的一個(gè)下屬機(jī)構(gòu)。因?yàn)楫?dāng)時(shí)規(guī)劃中要將北方電信的數(shù)據(jù)中心合并，因此在那個(gè)時(shí)間段里凍結(jié)了系統(tǒng)升級(jí)改造，只能通過(guò)整體優(yōu)化來(lái)維持三年左右的穩(wěn)定運(yùn)行。

目前的情況與20年前十分相似，很多系統(tǒng)在2027年底前可能就面臨要更換為國(guó)產(chǎn)化設(shè)備了，因此這些年擴(kuò)容和改造系統(tǒng)的投資肯定是會(huì)受到限制的。采用成本相對(duì)較低的數(shù)據(jù)庫(kù)優(yōu)化可能是保持當(dāng)前系統(tǒng)穩(wěn)定運(yùn)行，應(yīng)對(duì)近期業(yè)務(wù)增長(zhǎng)的一種比較好的方法，在系統(tǒng)優(yōu)化工作中，類(lèi)似DBA優(yōu)化日記中的場(chǎng)景可能也會(huì)再次出現(xiàn)。

不同的DBA所經(jīng)歷過(guò)的優(yōu)化工作都會(huì)有所不同，這是因?yàn)樗麄兠鎸?duì)的客戶(hù)的優(yōu)化需求是不同的。有些用戶(hù)就是幾條爛SQL引發(fā)了問(wèn)題，那么解決掉這幾條SQL的問(wèn)題就沒(méi)啥可優(yōu)化的事情做了。這種情況投入較大的資金去全面優(yōu)化，其實(shí)是沒(méi)有什么必要的。我想大多數(shù)DBA以前面對(duì)的優(yōu)化項(xiàng)目可能大多如此，這也是我們?cè)谟懻搩?yōu)化的時(shí)候，很多DBA覺(jué)得能做SQL優(yōu)化才是DBA最牛叉的技能。隨著AI技術(shù)的發(fā)展，我倒是覺(jué)得SQL優(yōu)化是最容易被AI替代的技能，其門(mén)檻會(huì)快速降低。因?yàn)镾QL優(yōu)化的規(guī)則相對(duì)固定，用例也廣泛存在，比較容易獲取。前陣子遇到一條PG的SQL性能問(wèn)題，執(zhí)行計(jì)劃有八九十行，不想看，就直接扔給kimi了，沒(méi)想到KIMI的回答十分靠譜，依托KIMI的建議，我花了5分鐘就把問(wèn)題找到了。

大家也不用被KIMI的能力嚇到了，雖然在SQL優(yōu)化領(lǐng)域AI有著強(qiáng)大的潛力，不過(guò)優(yōu)化依然是一個(gè)離不開(kāi)專(zhuān)家的工作。面對(duì)一個(gè)復(fù)雜的系統(tǒng)的時(shí)候，SQL優(yōu)化可能只能解決一些表面的問(wèn)題，通過(guò)降低系統(tǒng)的負(fù)載和開(kāi)銷(xiāo)來(lái)達(dá)到優(yōu)化的目的永遠(yuǎn)是可行的，但是也存在一個(gè)問(wèn)題 ，那就是只解決了表層問(wèn)題，并沒(méi)有解決底層問(wèn)題。如果數(shù)據(jù)庫(kù)的配置存在不合理的配置項(xiàng)，那么這個(gè)配置項(xiàng)將會(huì)在數(shù)據(jù)庫(kù)的某種負(fù)載或者并發(fā)達(dá)到某個(gè)極限的時(shí)候爆發(fā)，出現(xiàn)故障。如果數(shù)據(jù)庫(kù)底層的操作系統(tǒng)存在一個(gè)對(duì)于某種數(shù)據(jù)庫(kù)不合理的配置參數(shù)，也會(huì)產(chǎn)生類(lèi)似的瓶頸。數(shù)據(jù)庫(kù)的底層硬件存在某個(gè)不合理的瓶頸，網(wǎng)絡(luò)參數(shù)存在某個(gè)不合理的配置，都可以在某種負(fù)載下出現(xiàn) 不穩(wěn)定或者性能下降，這些問(wèn)題往往隱藏得很深，不做全面優(yōu)化分析都很難找出來(lái)。

前些天我的一個(gè)客戶(hù)的PG數(shù)據(jù)庫(kù)FREEEZE了，只能進(jìn)入單用戶(hù)狀態(tài)去做VACUUM FREEZE，否則數(shù)據(jù)庫(kù)都起不來(lái)了。事后我把我以前寫(xiě)過(guò)的一篇文章發(fā)給他，讓他們根據(jù)文章要求去優(yōu)化一下參數(shù)。他們覺(jué)得很奇怪，都搞定了，為啥還要去優(yōu)化參數(shù)。我說(shuō)如果不優(yōu)化參數(shù)，下回還會(huì)出事。他們照著去做了，然后說(shuō)以后是不是可以高枕無(wú)憂(yōu)了。我說(shuō)不行，因?yàn)檫@是PG的一個(gè)巨大的缺陷，優(yōu)化了參數(shù)當(dāng)前可能不會(huì)出問(wèn)題了，但是說(shuō)不準(zhǔn)在某些特定情況下還是會(huì)出問(wèn)題。因此需要針對(duì)FREEZE情況做日常監(jiān)控，最好做個(gè)監(jiān)控項(xiàng)和月度巡檢項(xiàng)，隨時(shí)關(guān)注這個(gè)問(wèn)題。出問(wèn)題前提前處置，就不至于像這回一樣，搞出一個(gè)停機(jī)幾個(gè)小時(shí)的故障了。

這種運(yùn)維運(yùn)營(yíng)工作上的優(yōu)化也是優(yōu)化的一種形式，優(yōu)化的目的是保障業(yè)務(wù)連續(xù)性和客戶(hù)體驗(yàn)，因此優(yōu)化其實(shí)是個(gè)綜合性的問(wèn)題。對(duì)于絕大多數(shù)DBA參與過(guò)的優(yōu)化工作而言，都好像是盲人摸象一樣，可能只是摸到了優(yōu)化工作的一條腿或者一只耳朵而已。