給國產資料庫廠商提個建議：把慢SQL監控升級為關鍵SQL管理

慢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監控跟蹤能力的資料輸出，更好的為資料庫信創替代服務。