背景
前面的文章寫過 MySQL 的事務(wù)和鎖劫哼，這篇文章我們來聊聊 MySQL 的 Explain萝映，估計大家在工作或者面試中多多少少都會接觸過這個。可能工作中實際使用的不多宫静，但是不論的自己學(xué)習(xí)還是面試污呼，都需要掌握的达罗。
Explain 可以使用在SELECT, DELETE, INSERT, REPLACE, and UPDATE 語句中低斋，執(zhí)行的結(jié)果會在每一行顯示用到的每一個表的詳細(xì)信息。簡單語句可能結(jié)果就只有一行愉择，但是復(fù)雜的查詢語句會有很多行數(shù)據(jù)劫乱。
Explain 的使用
在 SQL 語句前面加上 explain织中，如：EXPLAIN SELECT * FROM a;
舉個例子
采用上面的語句EXPLAIN SELECT * FROM a;，效果如下
通過圖片我們可以看到執(zhí)行過后會輸出 12 個字段要拂，那么每個字段是什么意思呢抠璃？我們來一一看下
Explain 輸出的字段內(nèi)容
id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows,filtered,extra
| 列名 | 含義 |
|---|---|
| id | 查詢語句的標(biāo)識 |
| select_type | 查詢的類型 |
| table | 當(dāng)前行所查的表 |
| partitions | 匹配的分區(qū) |
| type | 訪問類型 |
| possible_keys | 查詢可能用到的索引 |
| key | mysql 決定采用的索引來優(yōu)化查詢 |
| key_len | 索引 key 的長度 |
| ref | 顯示了之前的表在key列記錄的索引中查找值所用的列或常量 |
| rows | 查詢掃描的行數(shù)，預(yù)估值脱惰，不一定準(zhǔn)確 |
| filtered | 查詢的表行占表的百分比 |
| extra | 額外的查詢輔助信息 |
常用字段詳細(xì)介紹
1.id: 是用來順序標(biāo)識整個查詢中 select 語句的，在嵌套查詢中id越大的語句越先執(zhí)行2.select_type:
?simple: 簡單的SELECT（不使用UNION或子查詢）?primary: 最外面的SELECT?union: UNION中的第二個或更高的SELECT語句?dependent union: UNION中的第二個或更高的SELECT語句窿春，取決于外部查詢?union result: UNION的結(jié)果?subquery: 在子查詢中首先選擇SELECT?dependent subquery: 子查詢中的第一個SELECT拉一，取決于外部查詢?derived: 派生表——該臨時表是從子查詢派生出來的，位于from中的子查詢?uncacheable subquery: 無法緩存結(jié)果的子查詢旧乞，必須為外部查詢的每一行重新計算?uncacheable union: 在UNION中的第二個或更晚的選擇屬于不可緩存的子查詢
3.table: 每一行引用的表名4.type: 從上到下效果依次降低
?system: const 的一種特例蔚润，表中只有一行數(shù)據(jù)?const: 當(dāng)確定最多只會有一行匹配的時候，MySQL優(yōu)化器會在查詢前讀取它而且只讀取一次尺栖，因此非车站溃快。使用主鍵查詢往往就是 const 級別的延赌，非常高效?eq_ref: 最多只返回一條符合條件的記錄除盏，通過使用在兩個表有關(guān)聯(lián)字段的時候?ref: 通過普通索引查詢匹配的很多行時的類型?fulltext: 全文索引?ref_or_null: 跟 ref 類似的效果，不過多一個列不能 null 的條件?index_merge: 此連接類型表示使用了索引合并優(yōu)化挫以。在這種情況下者蠕，輸出行中的 key 列包含使用的索引列表，key_len包含所用索引的最長 key 部分列表?unique_subquery: 在使用 in 查詢的情況下會取代 eq_ref?range: 范圍掃描掐松，一個有限制的索引掃描踱侣。key 列顯示使用了哪個索引。當(dāng)使用=大磺、 <>抡句、>、>=杠愧、<待榔、<=、IS NULL殴蹄、<=>究抓、BETWEEN 或者 IN 操作符，用常量比較關(guān)鍵字列時,可以使用 range?index: 類似全表掃描袭灯，只是掃描表的時候按照索引次序進(jìn)行而不是行刺下。主要優(yōu)點就是避免了排序, 但是開銷仍然非常大。如在Extra列看到Using index稽荧，說明正在使用覆蓋索引橘茉，只掃描索引的數(shù)據(jù)工腋，它比按索引次序全表掃描的開銷要小很多?ALL: 全表掃描
5.possible_key: MySQL 可能采用的索引，但是并不一定使用6.key: MySQL 正真使用的索引名稱7.rows: 預(yù)估的掃描行數(shù)畅卓，只能參考不準(zhǔn)確8.extra: 該列包含了很多額外的信息擅腰，包括是否文件排序，是否有臨時表等翁潘，很多時候這個字段很有用能提供很多信息
