AI驅動的數據庫智能診斷：從“救火”到“防火”

本文通過 AI Agent 技術實現數據庫異常的自動發現、智能分析和快速修復，將故障處理時間從數小時縮短到分鐘級，異常誤報率降低 60-80%。

背景：三大核心痛點

隨著業務規?？焖僭鲩L，OPPO的數據庫規模已達到數十萬實例、千萬級庫表，涵蓋MySQL、PostgreSQL、MongoDB、ClickHouse、Redis、Milvus等多種數據庫類型。常見故障點：

圖1：數據庫常見故障點

分析發現：

• 80%的故障時間花在問題分析與根因定位
• 平均故障處理時長195分鐘，70%為性能調優問題

傳統的人工診斷模式面臨三大核心痛點：

AI智能診斷：三大核心優勢

基于AI Agent構建的智能診斷系統，相比傳統診斷具有三大核心優勢

2.1 多模態融合診斷

傳統方式：孤立指標檢查 + 人工經驗關聯

AI方式：同時處理數百個指標，自動發現隱式關聯，融合5種數據模態:

1. 指標時序數據（Prometheus/Grafana）
2. 文本日志（錯誤日志、慢查詢日志）
3. 配置信息（my.cnf等）
4. SQL文本（查詢語句、執行計劃）
5. 拓撲結構（主從關系、分片信息）

案例：

數據庫突然變慢：
指標：QPS下降50%
日志：大量"Lock wait timeout"錯誤
SQL：UPDATE執行時間從10ms增加到5s
配置：innodb_lock_wait_timeout設置為50s（過長）
拓撲：UPDATE在從庫執行（錯誤）
AI判斷：應用錯誤路由到從庫 → 從庫只讀阻塞 → 連接池耗盡 → QPS下降

價值：排查時間從數小時縮短到分鐘級

2.2 動態自適應診斷

傳統方式：閾值固定，無法區分“正常的高負載”與“異常的高負載”

AI方式：

1. 自動識別業務流量變化：工作日 vs 周末、業務高峰期 vs 低峰期
2. 異常評分：使用綜合評分規則給出異常程度
3. 遷移學習：將A庫的診斷經驗遷移到B庫（同架構、不同業務）

案例：

傳統：CPU 85% → 告警（可能是正常業務高峰）
AI： CPU 85% + 查詢模式異常 + 連接數突增 + 歷史同期對比→ 綜合評分0.92（高度異常）→ 告警

價值：異常誤報率降低60-80%

2.3 預測性診斷

傳統流程：問題發生 → 用戶投訴 → DBA介入 → 分析 → 解決（已造成影響）

AI能力：

1. 時序預測：預測未來1-24小時性能趨勢
2. 故障預測：磁盤空間、容量預警
3. 性能退化預警：提前發現索引效率下降

案例：

AI模型輸入：
- 磁盤空間增長率（指數增長趨勢）
- 表大小增長率
- 歷史清理周期
AI輸出：
"預計3天后磁盤將滿，建議立即執行歸檔操作"

價值：從"救火"到"防火"，故障從"已發生"提前到"即將發生"

技術架構：ODC+知識庫+AI Agent

3.1 整體架構

• 多數據庫類型：OLTP、文檔型、分析型、鍵值型、AI新業態型數據庫
• 多模數據管理平臺：OneMeta：各數據庫類型在系統變成“可理解、可治理、可查詢”統一數據資產；OneOps：提供DBaaS（數據庫即服務）的體驗，所有運維相關操作的控制平臺
• AI驅動：構建數據庫知識庫，融合專家經驗+AI Agent
• AI應用：多種場景如開發提效、智能診斷、智能運維自治

圖2：AI智能診斷系統整體架構

多模數據管理平臺ODC(Open Database Develop Center)已經完成并投入使用，不做過多說明。本文主要介紹智能診斷模塊的實現，開發提效和智能運維模塊后續再做詳細介紹。

3.2 智能診斷核心組件

OneMetrics：統一監控指標輸入與異常監測

• 運行日志：慢日志、錯誤日志、審計日志
• 性能指標：CPU、內存、IO、連接數等
• 操作日志：擴縮容、主從切換、參數修改

診斷自治服務：專家經驗 + AI Agent

• 異常識別：自動識別CPU飆高、慢日志激增等
• 異常分析：AAS分析 + AI Agent智能診斷
• 異常定位：基于RAG的檢索增強生成

圖3：診斷自治服務流程圖

核心技術：專家經驗+RAG增強型AI

4.1 診斷演進路徑

4.2 診斷流程：識別→分析→定位

圖4：智能診斷方案

4.2.1 異常識別

依賴數據采集時的監測，自動識別異常場景：

• CPU飆高
• 內存異常
• 慢日志激增
• 錯誤日志
• 主從切換
• 整庫整表刪除
• 其他異常場景

4.2.2 異常分析

專家經驗部分：

以AAS（平均活躍會話數）作為切入點：

• AAS數量變化趨勢反映數據庫實例負載變化
• 優先處理AAS數量較多的會話狀態
• 快速初步定位根因

AI Agent部分：

將以下信息作為輸入，以Prompt形式發送給AI Agent：

• 異常信息
• 審計日志
• 慢日志
• 錯誤日志
• AAS數據
• 操作日志
• 監控指標
• 特殊指標

AI Agent進行預設的分析流程進行智能診斷分析，輸出診斷結果。

4.2.3 異常定位

技術方案：基于RAG（Retrieval-Augmented Generation，檢索增強生成）

圖5：基于RAG的異常定位技術架構

RAG的優勢：

? 結合通用知識庫和人工標注結果

? 融入企業私有業務知識

? 顯著提升準確性，減少AI幻覺

? 調用OneMeta API，增強診斷準確性

反饋閉環：

用戶對診斷結果評價后：

• 將Prompt和用戶標注結果輸入嵌入式模型
• 更新知識庫
• 持續優化診斷效果

4.3 結果評估：雙重保障

AI評估

使用AI小模型對DB Agent輸出進行評估：

人工評估

• 用戶評估：對診斷結果準確性和采納與否進行評估
• 專家評估：專家對結果的準確性、相關性、安全性再次評估
• 知識庫更新：剔除badcase，存入優質案例，持續優化

重要性：雖然評估成本較大，但這是提高DB Agent準確率的"良方"，尤其在數據庫這種基礎高風險組件中尤為重要。

實戰案例：CPU飆高診斷

5.1 異常監測

進入性能診斷界面，發現CPU使用率在21:03:00-21:13:00突然飆高至85%，觸發智能診斷。

圖6：CPU使用率異常監測界面

5.2 根因分析與定位

通過AAS（平均活躍會話數）分析發現：

• 數據庫Sending_data負載最大
• AAS數量變化趨勢與CPU飆高時間段完全吻合
• 業務Send數據量和MySQL的TPS增多，相互佐證

圖7：AAS分析圖

推斷：CPU飆高由數據庫查詢時Sending_data數據過多引起。通過SQL關聯分析，定位到導致CPU飆高的SQL指紋。

5.3 優化建議

AI提供索引建議和SQL改寫建議，一鍵跳轉ODC數據變更界面。

圖8：SQL優化建議界面

核心價值與展望

1. 核心成果

• 異常發現及時性：從被動響應到主動預測
• 根因診斷高效性：從數小時縮短到分鐘級
• 異常告警準確性：異常誤報降低60-80%

2. 技術亮點

• 多模態融合：融合指標、日志、配置、SQL、拓撲等多源數據
• RAG增強生成：結合知識庫和專家經驗，提升診斷準確性
• 雙軌制保障：專家經驗+AI，保證穩定性
• 反饋閉環：用戶和專家評估，持續優化

3. 未來方向

• 持續優化AI模型，提升診斷準確率
• 擴展更多數據庫類型支持
• 增強預測性診斷能力
• 完善自動化修復能力

總結

數據庫智能診斷實現了資源監控與SQL智能關聯，精準鎖定異常根因，提供優化方案，形成異常發現-診斷-修復閉環。

AI的診斷結果并非完全準確，部分重要場景仍需要人為干預和引導。DB Agent的建設是一條持續且漫長的道路，需要我們不斷優化與改進。