MySQL 慢查詢治理體系：從 Slow Log 到實時節點監控的演進之路

「查詢變慢」是數據庫最常見症狀，但傳統「Zabbix 監控 + 週報 + Slow Log Top 10」三板斧在高併發、大數據量場景下失效：監控不準、週報不及時、Top 10 被定時任務佔據。本文揭示構建輕量級、實時、可過濾、自動保存現場的慢查詢治理體系的關鍵設計。

一、 傳統方案三大痛點

二、 現代治理體系四大支柱

1. 實時 Slow Log 采集與解析

-- 動態開啟，閾值 1 秒
SET GLOBAL slow_query_log=ON;
SET GLOBAL long_query_time=1;
SET GLOBAL slow_query_log_file='/var/log/mysql/slow.log';
-- my.cnf 固化
[mysqld]
slow_query_log=1
long_query_time=1
slow_query_log_file=/var/log/mysql/slow.log

採用 pt-query-digest 或自研 Go/Python 解析器，流式處理，不落盤全量日誌，秒級產出指標。

2. 智能過濾與分級

• 白名單過濾：已知必跑的定時任務、大表歸檔、備份查詢，配置正則排除。
• 指紋聚合：抽象字面值，同模式 SQL 合併統計（如 SELECT * FROM t WHERE id=?）。
• 分級告警：
  P0：rows_examined > 100万 且 exec_time > 5s → 即時電話/短信
  P1：rows_examined > 10万 → 工單派單
  P2：no_index_used=1 → 納入優化待辦

3. 異常現場自動保存

• 連接數突增時，自動 SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS、SHOW GLOBAL STATUS 存入對象存儲，事後複盤有據可查。
• Binlog 位點記錄，配合 mysqlbinlog 精準定位異常時間窗口。

4. 統一查詢審計入口

所有上線 SQL 必須通過審計平台：
• 靜態分析：EXPLAIN、索引覆蓋、禁止 SELECT *、禁止隱式轉換
• 動態驗證：預發環境跑真實數據量，收集 rows_examined、exec_time
• 策略引擎：自動拒絕不符合規範的 SQL 發布

三、 關鍵配置參數速查

四、 成果指標

• 慢查詢發現時間：天級 → 秒級
• 業務影響時長：小時級 → 分鐘級
• 優化工單處理率：30% → 95%+
• 誤報率：通過白名單/指紋降至 < 5%

慢查詢治理不是跑腳本，是建系統。輕量級節點監控 + 智能過濾 + 自動現場保存，才是高併發時代的標配。