EXPLAIN 是分析 SQL 執行計畫的核心工具,能揭示優化器如何存取表、使用索引、連接順序等關鍵資訊。
| 欄位 | 含義 | 關鍵判讀 |
|---|---|---|
id | SELECT 識別序號 | 相同 id 從上往下執行;id 越大優先級越高 |
select_type | 查詢類型 | 見下文詳細分類 |
table | 存取的表 | <derivedN> 衍生表、<unionM,N> 聯合結果 |
type | 存取策略 | 核心指標,由好到壞:system > const > eq_ref > ref > range > index > ALL |
possible_keys | 可能用到的索引 | 為 NULL 表示無可用索引,需檢查 WHERE/ON 條件 |
key | 實際使用的索引 | 可用 FORCE/USE/IGNORE INDEX 干預 |
key_len | 索引長度 | 越短越好(不失精度前提),推斷複合索引用到第幾列 |
ref | 比較引用 | 顯示哪欄或常數與 key 配合使用 |
rows | 預估掃描行數 | InnoDB 為估算值,越小越好 |
Extra | 額外資訊 | Using index(覆蓋索引)、Using where、Using filesort(需優化)、Using temporary(需優化) |
system > const > eq_ref > ref > fulltext > ref_or_null >
index_merge > unique_subquery > index_subquery > range > index > ALL
底線:至少達到 range,最佳達到 ref 或 eq_ref。
varchar = 123)LIKE '%abc%' 不走索引,LIKE 'abc%' 可走CHAR,變長用 VARCHAR,長度剛好夠用PROCEDURE ANALYSE() 可建議轉型SELECT *:只取需要欄位,減少 IO、利用覆蓋索引COUNT(*) 謹慎用:InnoDB 無鎖計數但需全表掃描,考慮計數表或緩存GROUP BY 而非 DISTINCT:某些版本 GROUP BY 更優USE INDEXLIMIT M, N 深分頁陷阱:大偏移量極慢,改用游標/延遲關聯ORDER BY RAND() 禁用:全表掃描+排序,改用應用層隨機IN (SELECT...) → EXISTS 或 JOININSERT ... ON DUPLICATE KEY UPDATE 替代 SELECT+UPDATEMAX() 無索引:用索引列 + ORDER BY DESC LIMIT 1OPTIMIZE TABLE:碎片整理,尤其變長列頻繁更新刪除的表EXPLAIN 例行化審計當 Extra 顯示 Using index 時,查詢僅掃描索引樹,無需回表,效能提升數量級。設計複合索引時,將 SELECT、WHERE、ORDER BY 涉及的列按「等值篩選 → 範圍篩選 → 排序」順序排列,最大化覆蓋索引命中率。
查詢優化非一次性動作,而是「監控 → 分析 → 優化 → 驗證」的持續循環。掌握 EXPLAIN 讀圖能力,內化上述 20+ 原則,配合慢查詢日誌例行審計,才能在業務增長中守住資料庫效能底線。