MySQL Explain詳解
explain命令：可查看SQL語句的執行計划，查看SQL語句有沒有使用上了索引，有沒有做全表掃描，這都可以通過explain命令來查看。
具體操作是：select前添加explain來實現，它可以告訴我們你的語句性能如何。
平常查詢：(MySQL逐條統計，當數據過大時，想看到結果很費時間)
利用explain命令查看SQL語句的執行計划：
概要描述：
| 1 | id | select的識別符，這是select的查詢序列號。 |
| 2 | select_type： |
select的類型。SELECT類型,可以為以下任何一種：
|
| 3 | table | 輸出結果集的表格。 |
| 4 | partitions |
匹配的分區。 |
| 5 | type |
對表訪問方式。表示MySQL在表中找到所需行的方式，又稱“訪問類型”。 ”訪問類型“，按照從 '' 最佳類型--最壞類型 '' 進行排序：
|
| 6 | possible_keys |
表示查詢時，可能使用的索引。( MySQL能使用哪個索引在該表中找到行) |
| 7 | key |
實際使用的索引(鍵)，必然包含在possible_keys中。如果沒有選擇索引，索引是NULL。 要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。 |
| 8 | key_len |
索引的長度 ( 使用的字節數 )。如果索引是NULL，則長度為NULL。不損失精確性的情況下，長度越短越好 。 key_len顯示的值為索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的。 |
| 9 | ref |
使用哪個列或常數，與索引一起被用於從表中查找索引列上的值。( 列與索引的比較，表示上述表的連接匹配條件。) 顯示索引的哪一列被使用了，如果可能得話，是一個常數。 |
| 10 | rows |
MySQL認為它執行查詢時必須檢查的行數。( 掃描出的行數 [估算的行數 ]。) |
| 11 | filtered |
通過表條件過濾出的行數的百分比估計值。 |
| 12 | Extra |
Mysql執行情況的描述和詳細說明。
|
| 總結： • EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況。 • EXPLAIN不考慮各種Cache(緩存)。 • EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作。 • 部分統計信息是估算的，並非精確值。 • EXPALIN只能解釋SELECT操作，其他操作要重寫為SELECT后查看執行計划。 |
||
對這些字段進一步描述：
一、id
SELECT識別符。這是SELECT的查詢序列號。
我的理解是SQL執行的順序的標識，SQL從大到小的執行。
1. id如果相同，可以認為是一組，由上至下順序執行；
2. 在所有組中，id值越大，優先級越高，越先執行；
3. 如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行；
二、select_type
SELECT類型,可以為以下任何一種：
- SIMPLE（simple）：簡單SELECT(不使用UNION或子查詢)。
- PRIMARY（primary）：子查詢中最外層查詢，查詢中若包含任何復雜的子部分，最外層的select被標記為PRIMARY。
- UNION（union）：UNION中的第二個或后面的SELECT語句。
- DEPENDENT UNION（dependent union）：UNION中的第二個或后面的SELECT語句,取決於外面的查詢。
- UNION RESULT（union result）：UNION的結果，union語句中第二個select開始后面所有select。
- SUBQUERY（subquery）：子查詢中的第一個SELECT，結果不依賴於外部查詢。
- DEPENDENT SUBQUERY（dependent subquery）：子查詢中的第一個SELECT，依賴於外部查詢。
- DERIVED（derived）：派生表的SELECT (FROM子句的子查詢)。
- UNCACHEABLE SUBQUERY（uncacheable subquery）：(一個子查詢的結果不能被緩存，必須重新評估外鏈接的第一行)
顯示這一步所訪問數據庫中 '' 表名稱 ''（顯示這一行的數據是關於哪張表的），有時不是真實的表名字，可能是簡稱。
四、partitions
四、partitions
匹配的分區。
五、type
對表訪問方式。表示MySQL在表中找到所需行的方式，又稱“訪問類型”。
”訪問類型“，按照從 '' 最佳類型--最壞類型 '' 進行排序：
”訪問類型“，按照從 '' 最佳類型--最壞類型 '' 進行排序：
- NULL： MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引，例如從一個索引列里選取最小值可以通過單獨索引查找完成。
- system：表僅有一行(=系統表)。這是const聯接類型的一個特例。當MySQL對查詢某部分進行優化，並轉換為一個常量時，使用這些類型( system/const )訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換為一個常量。當查詢的表只有一行的情況下，使用system。
- const：表最多有一個匹配行，它將在查詢開始時被讀取。因為僅有一行，在這行的列值可被優化器剩余部分認為是常數。const表很快，因為它們只讀取一次！
- eq_ref：類似ref，區別就在使用的索引是唯一索引，對於每個索引鍵值，表中只有一條記錄匹配，簡單來說，就是多表連接中使用primary key或者 unique key作為關聯條件。這可能是最好的聯接類型，除了const類型。
- ref：表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值。
- ref_or_null：該聯接類型如同ref，但是添加了MySQL可以專門搜索包含NULL值的行。
- index_merge：該聯接類型表示使用了索引合並優化方法。【不常用】
- unique_subquery：該類型替換了下面形式的IN子查詢的 ref：value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一個索引查找函數，可以完全替換子查詢，效率更高。【不常用】
- index_subquery：該聯接類型類似於unique_subquery。可以替換IN子查詢，但只適合下列形式的子查詢中的非唯一索引：value IN (SELECT key_column FROM single_table WHERE some_expr)。【不常用】
- range：只檢索給定范圍的行，使用一個索引來選擇行。
- index：該聯接類型與ALL相同，Full Index Scan，index與ALL區別為index類型只遍歷索引樹。這通常比ALL快，因為索引文件通常比數據文件小。
- ALL：Full Table Scan， MySQL將遍歷全表以找到匹配的行。
- type顯示的是訪問類型，是較為重要的一個指標，結果值從好到壞依次是：Null > system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
- 一般來說，得保證查詢至少達到range級別，最好能達到ref。
- 我們在進行條件查詢時，建議使用索引，否則將引起全表掃描，IO的開銷和程序的性能都沒法保證！
表示查詢時，可能使用的索引。( MySQL能使用哪個索引在該表中找到行)。
指出MySQL能使用哪個索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用（該查詢可以利用的索引，如果沒有任何索引顯示 null）
該列完全獨立於EXPLAIN輸出所示的表的次序。這意味着在possible_keys中的某些鍵實際上不能按生成的表次序使用。
如果該列是NULL，則沒有相關的索引。在這種情況下，可以通過檢查WHERE子句看是否它引用某些列或適合索引的列來提高你的查詢性能。如果是這樣，創造一個適當的索引並且再次用EXPLAIN檢查查詢
六、Key
實際使用的索引(鍵)，必然包含在possible_keys中。如果沒有選擇索引，索引是NULL。
要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
七、key_len
實際使用的索引(鍵)，必然包含在possible_keys中。如果沒有選擇索引，索引是NULL。
要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。
八、key_len
索引的長度 ( 使用的字節數 )。如果索引是NULL，則長度為NULL。不損失精確性的情況下，長度越短越好 。
key_len顯示的值為索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的。
九、ref
使用哪個列或常數，與索引一起被用於從表中查找索引列上的值。( 列與索引的比較，表示上述表的連接匹配條件。)
顯示索引的哪一列被使用了，如果可能得話，是一個常數。
十、rows
MySQL認為它執行查詢時必須檢查的行數。( 掃描出的行數 [估算的行數 ]。)
十一、filtered
通過表條件過濾出的行數的百分比估計值。
十二、Extra
Mysql執行情況的描述和詳細說明。
• EXPLAIN，不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況。
• EXPLAIN，不考慮各種Cache(緩存)。
• EXPLAIN，不能顯示MySQL在執行查詢時所作的優化工作。
• EXPLAIN，部分統計信息(rows)是估算的，並非精確值。
• EXPALIN，只能解釋SELECT操作，其他操作要重寫為SELECT后查看執行計划。
- Distinct：MySQL發現第1個匹配行后，停止為當前的行組合搜索更多的行。
- Not exists：MySQL能夠對查詢進行LEFT JOIN優化，發現1個匹配LEFT JOIN標准的行后，不再為前面的的行組合在該表內檢查更多的行。
- range checked for each record (index map: #)：MySQL沒有發現好的可以使用的索引，但發現如果來自前面的表的列值已知，可能部分索引可以使用。
- Using filesort：當Query中包含 order by 操作，而且無法利用索引完成的排序操作稱為“文件排序”。
- Using index：從只使用索引樹中的信息而不需要進一步搜索讀取實際的行來檢索表中的列信息。
- Using temporary：為了解決查詢，MySQL需要創建一個臨時表來容納結果集，常見於排序和分組查詢，常見於 group by、order by。
- Using where：不用讀取表中所有信息，僅通過索引就可以獲取所需數據，這發生在對表的全部的請求列都是同一個索引的部分的時候，表示mysql服務器將在存儲引擎檢索行后再進行過濾。
- Using sort_union(...)、Using union(...)、Using intersect(...)：這些函數說明如何為index_merge聯接類型合並索引掃描。
- Using index for group-by：類似於訪問表的Using index方式，Using index for group-by表示MySQL發現了一個索引，可以用來查詢GROUP BY或DISTINCT查詢的所有列，而不要額外搜索硬盤訪問實際的表。
- Using join buffer：改值強調了在獲取連接條件時沒有使用索引，並且需要連接緩沖區來存儲中間結果。如果出現了這個值，那應該注意，根據查詢的具體情況可能需要添加索引來改進能。
- Impossible where：這個值強調了where語句會導致沒有符合條件的行（通過收集統計信息不可能存在結果）。
- Select tables optimized away：這個值意味着僅通過使用索引，優化器可能僅從聚合函數結果中返回一行。
- No tables used：Query語句中使用from dual 或不含任何from子句。
• EXPLAIN，不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況。
• EXPLAIN，不考慮各種Cache(緩存)。
• EXPLAIN，不能顯示MySQL在執行查詢時所作的優化工作。
• EXPLAIN，部分統計信息(rows)是估算的，並非精確值。
• EXPALIN，只能解釋SELECT操作，其他操作要重寫為SELECT后查看執行計划。
參考文檔：官方文檔 + https://www.cnblogs.com/lori/p/8535037.html + https://www.cnblogs.com/tufujie/p/9413852.html