??之前看過很多根因定位的論文，大多數都是基于PC算法+隨機游走，而這些論文上的算法很難落地。去了解很多大廠的解決方案之后，發現他們基本上都是基于專家規則做分類。下面介紹一下華為opengauss的AI4DB中的慢SQL根因定位時如何實現的。根據他的這種方案，我們可以推廣到系統根因定位、日志系統的根因定位等。
??慢SQL一直是數據運維中的痛點問題，如何有效診斷慢SQL根因是當前一大難題，工具結合openGauss自身特點融合了現網DBA慢SQL診斷經驗，該工具可以支持慢SQL根因15+，能同時按照可能性大小輸出多個根因并提供針對性的建議。
先來看一下數據流圖：
參數配置
??1：在misc/dbmind.config中設置detection_interval（檢測的間隔），和last_detection_time（上次檢測距離本次多久）。
2：利用metadatabase/slow_queries.py在關系數據庫中建立如下表，方便前端系統獲取數據展示：
3：設置計算特征的閾值，也是在數據庫建表，你也可以保存在文件中或固定的代碼中：
4：模塊啟動時的其他參數
慢SQL和專家規則
1：慢SQL類(common/types/misc.py)
2：根因類(common/types/root_cause.py)
??每個根因由四部分組成，分別是根因類別、根因細節、根因的建議、根因等級。
3：根因映射（slow_sql/featurelib/feature_mapping.py）
4：定義根因的規則（slow_sql/featurelib/features.py）
?①：FEATURE_LIB[‘features’]
?這是一個75*22的矩陣，行表示樣本數可以是專家定義（針對一些根因，只需要一個特征被觸發，前20個樣本中大部分都是這樣的）的也可以是歷史慢SQL被打標簽。列代表抽取出的慢SQL的特征。
?②：FEATURE_LIB[‘labels’]
??①中樣本的標簽，1到17對應于根因映射中分C1到C17，C1到C16只需要一個特征就能觸發這些根因。
?③：FEATURE_LIB[‘weight_matrix’]
??這是一個17*22的矩陣，17代表根因數，22代表特征數，是由①中的features矩陣計算而來的，詳細計算過程在slow_sql/featurelib/feature_model.py中的calculate_weight函數
定時任務
和趨勢預測都是定時任務的腳本中app/timed_app.py
??1：檢測間隔
??2：從prometheus獲取最近時間（last_detection_time）的慢查詢集合。
??2：上次檢測距離本次多久，last_detection_time轉換為秒
??3：慢查詢診斷入口函數（并行檢測）
模塊入口
在app/diagnosis/query/init.py中（這個函數由上面的定時任務調用）：
??1：慢SQL診斷的核心類
??2：入口函數，接下來我們會進入該函數進行詳解
??3：如果遇到異常，默認返回該根因
診斷的核心類SlowSQLAnalyzer
核心入口run()函數：
??1：QueryContext是慢SQL對象的數據處理工廠類
??2：從慢SQL獲取數據庫的相關信息：庫、模式、表，以字典形式返回
??3：從2返回的字典中獲取schema信息，
??4：診斷的核心函數，
核心函數_analyze（）：
??1：對一些特殊情況（commit或關鍵字）直接匹配指定的根因
??2：正則找到所有SQL文本中所有schema.table，找到schmema和table
??3：把所有的schema.table替換為空，是SQL文本成文SQL pattern
??4：初始化各種類型的metrics（數據庫、表結構、鎖信息、系統信息）
??5：調用QueryFeature類的__call__函數，依次生成features列表中的每一個特征
?6:在第5步中生成的慢SQL根因和featurelib下的features.py下的權重矩陣計算距離，得到topk個最相似的根因
?7：遍歷根因封裝到慢SQL對象的屬性中
?8：如果沒有找到根因，以‘C_UNKNOW’根因返回
