如何獲取有效能問題的 SQL：三大來源與分析工具實戰

如何獲取有效能問題的 SQL：三大來源與分析工具實戰

系統化梳理效能問題 SQL 來源：使用者回報、慢查詢日誌、即時程序列表，並介紹三大分析工具實戰用法。

來源一：使用者回報

• 最直接但最被動，通常已造成業務影響
• 建立標準回報模板：錯誤時間、操作頁面、頻率、預期/實際耗時

來源二：慢查詢日誌 (核心主動發現機制)

啟用配置

[mysqld]
slow_query_log = ON
slow_query_log_file = /var/log/mysql/slow.log  # 建議與資料目錄分離
long_query_time = 0.001  # 1 毫秒 (預設 10 秒，生產建議 0.01-0.1)
log_queries_not_using_indexes = ON  # 記錄未用索引查詢

動態啟用：SET GLOBAL slow_query_log = ON;

日誌欄位解讀

# Time: 2016-10-10T23:18:38.123456Z
# User@Host: root[root] @ localhost [127.0.0.1]  Id: 17
# Query_time: 2.345  Lock_time: 0.001  Rows_sent: 100  Rows_examined: 1000000
SELECT * FROM large_table WHERE status = 1;

• Query_time：總耗時
• Lock_time：等待鎖時間
• Rows_examined：掃描行數 (關鍵指標，遠大於 Rows_sent 表示全表掃描/索引失效)

來源三：即時程序列表 (緊急排查)

SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE time > 60;  -- 找出執行超過 60 秒的查詢

或 SHOW FULL PROCESSLIST;

慢查詢分析三大工具

mysqldumpslow 參數速查

-s 排序: c(次數) t(時間) l(鎖時間) r(掃描行) at/al/ar(平均值)
-t N: 取前 N 筆
-g "pattern": 正則過濾

實務流程建議

1. 常態：啟用慢查詢日誌 (long_query_time=0.1)，每日 pt-query-digest 產出報表
2. 發現 Top SQL → EXPLAIN 分析執行計畫 → 判斷索引/結構/寫法問題
3. 優化驗證 → 觀察後續報表該 SQL 是否消失/耗時下降
4. 緊急：processlist 找長跑查詢 → KILL id 釋放資源 → 事後根因分析