explain 語句詳解
參考：https://segmentfault.com/a/1190000008131735
explain 寫在 select 前，如下
mysql> explain select * from user_info where id = 2\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: user_info
partitions: NULL
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: const
rows: 1
filtered: 100.00
Extra: NULL
1 row in set, 1 warning (0.00 sec)
- id: SELECT 查詢的標識符. 每個 SELECT 都會自動分配一個唯一的標識符.
- select_type: SELECT 查詢的類型.
- table: 查詢的是哪個表
- partitions: 匹配的分區
- type: join 類型
- possible_keys: 此次查詢中可能選用的索引
- key: 此次查詢中確切使用到的索引.
- ref: 哪個字段或常數與 key 一起被使用
- rows: 顯示此查詢一共掃描了多少行. 這個是一個估計值，當然是越小越好
- filtered: 表示此查詢條件所過濾的數據的百分比
- extra: 額外的信息
select_type 取值
- SIMPLE, 表示此查詢不包含 UNION 查詢或子查詢
- PRIMARY, 表示此查詢有 UNION，並且是最外層的查詢。
- UNION, 表示此查詢是 UNION 的第二或隨後的查詢
- DEPENDENT UNION, UNION 中的第二個或後面的查詢語句, 取決於外面的查詢
- UNION RESULT, UNION 的結果
- SUBQUERY, 子查詢中的第一個 SELECT
- DEPENDENT SUBQUERY: 子查詢中的第一個 SELECT, 取決於外面的查詢. 即子查詢依賴於外層查詢的結果.
type 取值
type 字段比較重要, 它提供了判斷查詢是否高效的重要依據依據. 通過 type 字段, 我們判斷此次查詢是 全表掃描 還是 索引掃描 等.
- system: 表中只有一條數據. 這個類型是特殊的 const 類型.
- const: 針對主鍵或唯一索引的等值查詢掃描, 最多隻返回一行數據. const 查詢速度非常快, 因爲它僅僅讀取一次即可.
- eq_ref: 此類型通常出現在多表的 join 查詢, 表示對於前表的每一個結果, 都只能匹配到後表的一行結果. 並且查詢的比較操作通常是 =, 查詢效率較高.
- ref: 此類型通常出現在多表的 join 查詢, 針對於非唯一或非主鍵索引, 或者是使用了 最左前綴 規則索引的查詢。還有我發現查詢分區表的所有分區的主鍵也會出現這個。
- range: 表示使用索引範圍查詢, 通過索引字段範圍獲取表中部分數據記錄. 這個類型通常出現在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中。當 type 是 range 時, 那麼 EXPLAIN 輸出的 ref 字段爲 NULL, 並且 key_len 字段是此次查詢中使用到的索引的最長的那個.
- index: 表示全索引掃描(full index scan), 和 ALL 類型類似, 只不過 ALL 類型是全表掃描, 而 index 類型則僅僅掃描所有的索引, 而不掃描數據。index 類型通常出現在 所要查詢的數據直接在索引樹中就可以獲取到, 而不需要掃描數據. 當是這種情況時, Extra 字段 會顯示 Using index。比如說
select id from xxtable - ALL: 表示全表掃描, 這個類型的查詢是性能最差的查詢之一. 通常來說, 我們的查詢不應該出現 ALL 類型的查詢, 因爲這樣的查詢在數據量大的情況下, 對數據庫的性能是巨大的災難. 如一個查詢是 ALL 類型查詢, 那麼一般來說可以對相應的字段添加索引來避免.
不同的 type 類型的性能關係如下:
ALL < index < range ~ index_merge < ref < eq_ref < const < system
ALL 類型因爲是全表掃描, 因此在相同的查詢條件下, 它是速度最慢的.而 index 類型的查詢雖然不是全表掃描, 但是它掃描了所有的索引, 因此比 ALL 類型的稍快.後面的幾種類型都是利用了索引來查詢數據, 因此可以過濾部分或大部分數據, 因此查詢效率就比較高了.
extra 取值
- Using index: "覆蓋索引掃描", 表示查詢在索引樹中就可查找所需數據, 不用掃描表數據文件, 往往說明性能不錯
- Using where Using index: 查詢的列被索引覆蓋，並且where篩選條件是索引列之一，但是不是索引的列，不是前導列。意味着無法直接通過索引查找來查詢到符合條件的數據
- Using index condition: 需要回表查詢，查詢的列不全在索引中。意味着查詢列的某一部分無法直接使用索引。
- Using where: 需要回表查詢，查詢的列未被索引覆蓋，where 篩選條件非索引列。意味着也就是沒有可用的索引查找，當然這裏也要考慮索引掃描+回表與表掃描的代價。
- Using filesort: 當 Extra 中有 Using filesort 時, 表示 MySQL 需額外的排序操作, 不能通過索引順序達到排序效果. 一般有 Using filesort, 都建議優化去掉, 因爲這樣的查詢 CPU 資源消耗大.
- Using temporary: 查詢有使用臨時表, 一般出現於排序, 分組和多表 join 的情況, 查詢效率不高, 建議優化.