?慢SQL監(jiān)控最早是MySQL的特色功能，在此之前，Oracle的AWR報(bào)告中提供TOP SQL分析。通過優(yōu)化TOP SQL來解決數(shù)據(jù)庫的性能問題，消除大型隱患是做Oracle優(yōu)化時(shí)經(jīng)常用的手段。早期的MySQL比較簡單，一旦系統(tǒng)中出現(xiàn)大量的慢SQL，整個(gè)單進(jìn)程的MySQL服務(wù)就會(huì)出嚴(yán)重的性能問題，因此慢SQL監(jiān)控一直是MySQL中十分重要的工具。

目前我們的國產(chǎn)數(shù)據(jù)庫受MySQL思想的影響很深，因此很多國產(chǎn)數(shù)據(jù)庫也提供慢SQL監(jiān)控的功能。只不過很多用戶用過之后，感覺這個(gè)功能在大多數(shù)情況下有些雞肋。打開監(jiān)控后系統(tǒng)開銷很大，而且監(jiān)控發(fā)現(xiàn)的SQL往往并不關(guān)鍵。因?yàn)榘l(fā)現(xiàn)的慢SQL往往本身就是比較復(fù)雜的查詢語句，執(zhí)行時(shí)間就比較長。大部分SQL優(yōu)化不優(yōu)化關(guān)系并不大。

這和我二十年前做數(shù)據(jù)庫優(yōu)化一樣，優(yōu)化了大量的TOP SQL，從數(shù)據(jù)庫的各項(xiàng)指標(biāo)上提升很大，CPU使用率也降低了不少，平均事務(wù)響應(yīng)時(shí)間也提升很大，但是系統(tǒng)的使用者的感受并不明顯。

實(shí)際上對于用戶來說，需要的關(guān)于SQL的可觀測性能力與我們的數(shù)據(jù)庫廠商提供的能力并不一致。用戶對于SQL監(jiān)控可觀測性接口的需求要復(fù)雜得多。不同的系統(tǒng)對于SQL監(jiān)控方面的需求也是不同的。

本月20號發(fā)布的D-SMART社區(qū)版V2.2中，我們會(huì)發(fā)布一個(gè)十分有趣的功能-就是關(guān)鍵SQL監(jiān)控。在V2.2中的關(guān)鍵SQL跟蹤會(huì)支持社區(qū)版支持的所有數(shù)據(jù)庫對象，包括Oracle、MySQL、達(dá)夢、PG系列（包括瀚高、高斯，金倉、海量、優(yōu)璇等）。

顧名思義“關(guān)鍵SQL”就是在系統(tǒng)中比較關(guān)鍵的SQL語句，一旦這些SQL出現(xiàn)問題，就會(huì)對系統(tǒng)的性能產(chǎn)生很大的影響，對核心業(yè)務(wù)產(chǎn)生影響。

最近我也遇到過幾個(gè)客戶遇到關(guān)鍵SQL性能問題導(dǎo)致核心業(yè)務(wù)被迫暫時(shí)下線的嚴(yán)重故障。其中有一個(gè)用戶前陣子問我能不能幫他們實(shí)時(shí)監(jiān)控SQL語句的執(zhí)行計(jì)劃，當(dāng)SQL執(zhí)行計(jì)劃出問題的時(shí)候能夠告警。我當(dāng)時(shí)的回答是，對于業(yè)務(wù)負(fù)載較大的大型系統(tǒng)中，直接監(jiān)控所有的執(zhí)行計(jì)劃既不必要，成本也過高，弄不好這個(gè)監(jiān)控反而會(huì)引發(fā)一些高并發(fā)執(zhí)行的SQL的性能問題。

后來我就考慮這個(gè)業(yè)務(wù)的需求是什么，用戶希望當(dāng)系統(tǒng)中某條SQL發(fā)生異常時(shí)能夠及時(shí)感知，及時(shí)告警，被及時(shí)識別出來。于是就有了關(guān)鍵SQL告警這個(gè)功能。這個(gè)功能在V2.1.6版本中就已經(jīng)上線了。

僅僅有告警還不能滿足一些用戶的需求，對于一些十分核心的系統(tǒng)，很多用戶希望構(gòu)建關(guān)鍵SQL監(jiān)控的能力。能夠在監(jiān)控大屏上很直觀地看到這些SQL的執(zhí)行情況。于是就有了關(guān)鍵SQL監(jiān)控這個(gè)功能。

關(guān)鍵SQL分為幾類，第一類是和關(guān)鍵業(yè)務(wù)與關(guān)鍵數(shù)據(jù)相關(guān)的SQL語句，這些SQL語句一旦執(zhí)行緩慢就會(huì)引發(fā)核心業(yè)務(wù)的問題；第二類是并發(fā)執(zhí)行量很大，并且訪問的表中的數(shù)據(jù)量可能出現(xiàn)較大變化，同時(shí)索引數(shù)量較多，容易出現(xiàn)執(zhí)行計(jì)劃錯(cuò)誤的SQL語句。這些語句一旦出現(xiàn)執(zhí)行計(jì)劃錯(cuò)誤，執(zhí)行成本可能會(huì)提高數(shù)百倍甚至上萬倍。一旦因?yàn)檫@些SQL而把CPU、內(nèi)存等資源耗盡了，那么系統(tǒng)也就會(huì)出大問題了。

實(shí)際上用戶所需要的對SQL執(zhí)行計(jì)劃的監(jiān)控功能，如果從監(jiān)控軟件的角度來做十分不合適，因此我們只能通過一些曲線的手段來解決客戶的關(guān)鍵SQL監(jiān)控預(yù)警的問題。如果這些事情由數(shù)據(jù)庫內(nèi)核來做，那么會(huì)簡單得多，也高效得多。比如關(guān)鍵SQL的發(fā)現(xiàn)，基于AI4DB的一些算法，可以更為精準(zhǔn)的發(fā)現(xiàn)真正的關(guān)鍵SQL，因?yàn)樵跀?shù)據(jù)庫的核心引擎中，具有更多的有效時(shí)間，可以做更為精準(zhǔn)的分析與判斷。

一些執(zhí)行十分頻繁的SQL語句，其執(zhí)行計(jì)劃變壞，執(zhí)行成本大幅提升，如果在SQL引擎中能夠輸出一些標(biāo)簽數(shù)據(jù)，那么監(jiān)控工具也就能夠更方便的進(jìn)行監(jiān)控了。這對于數(shù)據(jù)庫核心來說，只是舉手之勞，而如果要讓外掛的數(shù)據(jù)庫監(jiān)控工具來說，就十分困難了。

關(guān)鍵SQL的自動(dòng)標(biāo)注、執(zhí)行計(jì)劃變壞預(yù)警、SQL問題風(fēng)險(xiǎn)提示，以目前的軟硬件環(huán)境來說，這些功能完全可以在數(shù)據(jù)庫核心里實(shí)現(xiàn)，或者由SQL引擎內(nèi)核輸出一些關(guān)鍵數(shù)據(jù)，供運(yùn)維工具使用。而一些內(nèi)核中外掛的工具也可以利用數(shù)據(jù)庫的AI4DB能力，利用系統(tǒng)較為空閑的窗口進(jìn)行自動(dòng)分析，直接輸出一些分析報(bào)告。

數(shù)據(jù)庫信創(chuàng)替代工作開展后，運(yùn)維經(jīng)驗(yàn)的積累是個(gè)長期的過程，因此在短期內(nèi)，SQL優(yōu)化將是數(shù)據(jù)庫信創(chuàng)替代的關(guān)鍵業(yè)務(wù)。因此也希望我們的國產(chǎn)數(shù)據(jù)庫廠商打破思維的固有限制，不要被MySQL慢SQL監(jiān)控這種思路固化，在內(nèi)核中提升SQL監(jiān)控跟蹤能力的數(shù)據(jù)輸出，更好的為數(shù)據(jù)庫信創(chuàng)替代服務(wù)。?