要優化mysql性能，慢查詢日志是關鍵切入點。1. 開啟慢查詢日志可在配置文件中設置slow_query_log=1、指定日志路徑、設定long_query_time（如1秒）并記錄未使用索引的sql；也可在運行時用set global命令動態開啟。2. 查看日志需關注query_time（執行耗時）、lock_time（鎖等待時間）、rows_examined（掃描行數）和rows_sent（返回行數），這些指標反映sql性能狀況。3. 常見慢查詢原因包括：缺少合適索引導致全表掃描、索引使用不當（如對字段使用函數）、返回數據過多、join操作不合理。4. 優化建議包括添加索引、調整sql寫法、限制返回數據量、優化join邏輯，并通過explain分析執行計劃。5. 推薦使用mysqldumpslow、pt-query-digest等工具輔助分析日志，結合可視化平臺實現監控與趨勢分析，從而持續優化sql性能。
在MySQL性能優化中，慢查詢日志是最基礎、也最直接的切入點。很多數據庫問題其實都藏在慢查詢里，只要打開這個開關，就能看到“卡頓”的源頭。這篇文章講的是怎么用好慢查詢日志，從開啟到分析再到優化，一步步帶你理清思路。
如何開啟并配置慢查詢日志？
想看慢查詢日志，首先得讓它記錄下來。默認情況下，MySQL是不開啟這項功能的。你可以通過修改配置文件（通常是my.cnf或my.ini）來啟用：
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1
上面幾個參數的意思分別是：
- 開啟慢查詢日志
- 指定日志路徑
- 設置超過1秒的SQL為“慢”
- 記錄未使用索引的查詢
改完配置記得重啟MySQL服務或者重新加載配置。如果你不想重啟，也可以在運行時動態設置：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL log_queries_not_using_indexes = 'ON';
注意：有些系統上動態修改long_query_time后可能需要斷開當前連接才會生效。
怎么看懂慢查詢日志的內容？
慢查詢日志的格式其實挺直觀的。一條典型的日志長這樣：
# Time: 2025-04-05T10:00:01.123456Z # User@Host: root[root] @ localhost [] # Query_time: 2.123456 Lock_time: 0.000123 Rows_sent: 1 Rows_examined: 100000 SET timestamp=1717581601; SELECT * FROM orders WHERE user_id = 12345;
重點看這幾個指標：
- Query_time：整個查詢耗時，單位秒。這是判斷是否“慢”的關鍵。
- Lock_time：等待鎖的時間，如果很高，可能是表鎖競爭嚴重。
- Rows_examined：掃描了多少行數據。數值大說明沒走好索引。
- Rows_sent：實際返回給客戶端的數據行數。如果和掃描行數差很多，說明做了大量無效過濾。
有時候你會看到Rows_examined很大但Query_time卻不高，這可能是因為用了緩存（比如query cache），但這不是長久之計，還是得優化SQL本身。
常見慢查詢原因及優化建議
慢查詢的成因多種多樣，但最常見的幾種情況如下：
? 缺少合適的索引
一個沒有索引的where條件，可能導致全表掃描。比如下面這個語句：
SELECT * FROM users WHERE email = 'test@example.com';
如果email字段沒有索引，那每次執行都要掃全表。解決辦法很簡單：加索引。
ALTER TABLE users ADD INDEX idx_email (email);
? 索引使用不當
有時雖然加了索引，但SQL寫法不對，導致索引失效。例如：
SELECT * FROM orders WHERE DATE(created_at) = '2025-04-01';
這里用了函數處理字段，會讓索引失效。應該改成范圍查詢：
SELECT * FROM orders WHERE created_at >= '2025-04-01' AND created_at < '2025-04-02';
? 查詢返回太多數據
有時候一個SQL返回了幾千條甚至幾萬條數據，不僅慢還占資源。這時候要考慮是不是真的需要這么多數據，能不能分頁？能不能加條件限制？
? 關聯表太多或關聯方式不對
多表JOIN時如果沒有合理使用索引，或者JOIN順序不合理，也可能拖慢速度。建議：
- 盡量減少JOIN數量
- 被驅動表的JOIN字段要有索引
- 使用EXPLAIN查看執行計劃，看看有沒有Using filesort或臨時表
工具推薦：讓分析更高效
光靠看日志效率太低，可以用一些工具輔助分析：
-
mysqldumpslow：MySQL自帶的慢日志分析工具，能統計出現頻率高的慢SQL。
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log
上面命令按時間排序，顯示前10條慢SQL。
-
pt-query-digest（Percona Toolkit的一部分）：比mysqldumpslow強大很多，支持聚合分析、輸出報告等，適合做定期巡檢。
-
可視化平臺：像prometheus + grafana配合mysqld_exporter，可以實時監控慢查詢趨勢；有些公司也會自建慢查詢分析平臺，統一收集和展示。
基本上就這些。慢查詢日志看似簡單，但真要分析到位并不容易。關鍵是養成定期檢查的習慣，結合日志和執行計劃去定位問題。很多時候優化一條SQL，性能提升就能立竿見影。
