面對效能瓶頸，系統性的SQL調優流程比零散優化更關鍵。本文構建「頻率分析→慢查詢定位→執行計劃剖析」三階段調優方法論，並詳細解讀EXPLAIN輸出各欄位含義與優化指引。
SHOW STATUS LIKE 'Com_%';關鍵計數器：
Com_select、Com_insert、Com_update、Com_delete：各操作執行次數（批量INSERT僅計1次）Innodb_rows_read/inserted/updated/deleted：InnoDB層面行級統計，算法不同Com_commit/Com_rollback：事務提交/回滾頻率，回滾頻繁提示邏輯異常資料庫負載特徵判斷：以查詢為主？寫入為主？混合負載？
mysqld --log-slow-queries[=file_name] --long_query_time=N記錄執行超過N秒的SQL，適合定期審計。
SHOW [FULL] PROCESSLIST;即時查看執行中線程、狀態、鎖表情況，適合突發效能故障排查。
EXPLAIN SELECT SUM(moneys) FROM sales a JOIN company b
ON a.company_id = b.id WHERE a.year = 2023\G| 欄位 | 含義 | 關鍵判讀 |
|---|---|---|
| id | 查詢序號 | 同id按順序執行，不同id越大越先執行 |
| select_type | 查詢類型 | SIMPLE/PRIMARY/UNION/SUBQUERY/DERIVED |
| table | 輸出結果表 | 別名或衍生表 |
| type | 連接類型（效能關鍵） | system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL |
| possible_keys | 可能用到的索引 | 為空表示無索引可用 |
| key | 實際使用索引 | 為NULL表示全表掃描 |
| key_len | 索引長度 | 推斷複合索引用了幾列 |
| ref | 索引比較值來源 | const/函數/欄位名 |
| rows | 預估掃描行數 | 越小越好，統計資訊準確性關鍵 |
| Extra | 額外資訊 | Using index(覆蓋索引)/Using where/Using filesort/Using temporary |
-- 表a：type=ALL, key=NULL, rows=1000, Extra=Using where
-- 表b：type=ref, key=ind_company_id, rows=1, Extra=Using where;Using index
-- 診斷：表a無索引全表掃描1000行，表b走索引覆蓋查詢
-- 優化：為sales.year建立索引或複合索引(company_id, year)system/const：常量表/唯一索引等值查詢，極快eq_ref：主鍵/唯一索引JOIN，每行匹配1行ref：普通索引等值查詢/JOINrange：索引範圍掃描（>/</BETWEEN/IN）index：全索引掃描（覆蓋索引時出現）ALL：全表掃描，需優化建立「頻率基線→慢查詢收集→計劃剖析→索引優化→驗證回歸」閉環流程，是MySQL調優從藝術走向工程化的關鍵。
