?慢SQL監控最早是MySQL的特色功能，在此之前，Oracle的AWR報告中提供TOP SQL分析。通過優化TOP SQL來解決數據庫的性能問題，消除大型隱患是做Oracle優化時經常用的手段。早期的MySQL比較簡單，一旦系統中出現大量的慢SQL，整個單進程的MySQL服務就會出嚴重的性能問題，因此慢SQL監控一直是MySQL中十分重要的工具。

目前我們的國產數據庫受MySQL思想的影響很深，因此很多國產數據庫也提供慢SQL監控的功能。只不過很多用戶用過之后，感覺這個功能在大多數情況下有些雞肋。打開監控后系統開銷很大，而且監控發現的SQL往往并不關鍵。因為發現的慢SQL往往本身就是比較復雜的查詢語句，執行時間就比較長。大部分SQL優化不優化關系并不大。

這和我二十年前做數據庫優化一樣，優化了大量的TOP SQL，從數據庫的各項指標上提升很大，CPU使用率也降低了不少，平均事務響應時間也提升很大，但是系統的使用者的感受并不明顯。

實際上對于用戶來說，需要的關于SQL的可觀測性能力與我們的數據庫廠商提供的能力并不一致。用戶對于SQL監控可觀測性接口的需求要復雜得多。不同的系統對于SQL監控方面的需求也是不同的。

本月20號發布的D-SMART社區版V2.2中，我們會發布一個十分有趣的功能-就是關鍵SQL監控。在V2.2中的關鍵SQL跟蹤會支持社區版支持的所有數據庫對象，包括Oracle、MySQL、達夢、PG系列（包括瀚高、高斯，金倉、海量、優璇等）。

顧名思義“關鍵SQL”就是在系統中比較關鍵的SQL語句，一旦這些SQL出現問題，就會對系統的性能產生很大的影響，對核心業務產生影響。

最近我也遇到過幾個客戶遇到關鍵SQL性能問題導致核心業務被迫暫時下線的嚴重故障。其中有一個用戶前陣子問我能不能幫他們實時監控SQL語句的執行計劃，當SQL執行計劃出問題的時候能夠告警。我當時的回答是，對于業務負載較大的大型系統中，直接監控所有的執行計劃既不必要，成本也過高，弄不好這個監控反而會引發一些高并發執行的SQL的性能問題。

后來我就考慮這個業務的需求是什么，用戶希望當系統中某條SQL發生異常時能夠及時感知，及時告警，被及時識別出來。于是就有了關鍵SQL告警這個功能。這個功能在V2.1.6版本中就已經上線了。

僅僅有告警還不能滿足一些用戶的需求，對于一些十分核心的系統，很多用戶希望構建關鍵SQL監控的能力。能夠在監控大屏上很直觀地看到這些SQL的執行情況。于是就有了關鍵SQL監控這個功能。

關鍵SQL分為幾類，第一類是和關鍵業務與關鍵數據相關的SQL語句，這些SQL語句一旦執行緩慢就會引發核心業務的問題；第二類是并發執行量很大，并且訪問的表中的數據量可能出現較大變化，同時索引數量較多，容易出現執行計劃錯誤的SQL語句。這些語句一旦出現執行計劃錯誤，執行成本可能會提高數百倍甚至上萬倍。一旦因為這些SQL而把CPU、內存等資源耗盡了，那么系統也就會出大問題了。

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

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

關鍵SQL的自動標注、執行計劃變壞預警、SQL問題風險提示，以目前的軟硬件環境來說，這些功能完全可以在數據庫核心里實現，或者由SQL引擎內核輸出一些關鍵數據，供運維工具使用。而一些內核中外掛的工具也可以利用數據庫的AI4DB能力，利用系統較為空閑的窗口進行自動分析，直接輸出一些分析報告。

數據庫信創替代工作開展后，運維經驗的積累是個長期的過程，因此在短期內，SQL優化將是數據庫信創替代的關鍵業務。因此也希望我們的國產數據庫廠商打破思維的固有限制，不要被MySQL慢SQL監控這種思路固化，在內核中提升SQL監控跟蹤能力的數據輸出，更好的為數據庫信創替代服務。?