【渣渣程序員我不是DBA】MySQL的Explain記錄一下

寫一下Explain記錄一下

簡單粗暴的記錄一下，平常使用Explain是爲了查看目標SQL是否是用到了索引，也就是索引的使用狀況，可是，沒寫這篇文章以前我使用Explain全靠猜，寫這個的目的也是本身整理學習一下，ok，步入正題

使用場景通常就是這種：

在查詢語句以前加上explain，來分析SQL語句

mysql> explain select * from servers;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | servers | ALL  | NULL          | NULL | NULL    | NULL |    1 | NULL  |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
row in set (0.03 sec)

分析出來的結果有10列分別是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra，挨個解釋一遍，就不墨跡了

• ID

mysql執行計劃中的ID，ID若是相同，能夠認爲是一組，從上往下順序執行，在每組ID中，其中ID越大，優先級越高，越早執行

• select_type

(1) SIMPLE(簡單SELECT,不使用UNION或子查詢等)

(2) PRIMARY(查詢中若包含任何複雜的子部分,最外層的select被標記爲PRIMARY)

(3) UNION(UNION中的第二個或後面的SELECT語句)

(4) DEPENDENT UNION(UNION中的第二個或後面的SELECT語句，取決於外面的查詢)

(5) UNION RESULT(UNION的結果)

(6) SUBQUERY(子查詢中的第一個SELECT)

(7) DEPENDENT SUBQUERY(子查詢中的第一個SELECT，取決於外面的查詢)

(8) DERIVED(派生表的SELECT, FROM子句的子查詢)

(9) UNCACHEABLE SUBQUERY(一個子查詢的結果不能被緩存，必須從新評估外連接的第一行)

• table

查詢的哪一張表的信息

• type

查找到特定行，用到的類型，分爲如下幾種：
經常使用的類型有： ALL, index, range, ref, eq_ref, const, system, NULL（從左到右，性能從差到好）

具體的解釋：
ALL：Full Table Scan， MySQL進行了全表掃描以找到匹配的行

index: Full Index Scan，index與ALL區別爲index類型只遍歷索引樹

range:只檢索給定範圍的行，使用一個索引來選擇行

ref: 表示上述表的鏈接匹配條件，即哪些列或常量被用於查找索引列上的值

eq_ref: 相似ref，區別就在使用的索引是惟一索引，對於每一個索引鍵值，表中只有一條記錄匹配，簡單來講，就是多表鏈接中使用primary key或者 unique key做爲關聯條件

const、system: 當MySQL對查詢某部分進行優化，並轉換爲一個常量時，使用這些類型訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換爲一個常量,system是const類型的特例，當查詢的表只有一行的狀況下，使用system

NULL: MySQL在優化過程當中分解語句，執行時甚至不用訪問表或索引，例如從一個索引列裏選取最小值能夠經過單獨索引查找完成。

• possible_keys

指出MySQL能使用哪一個索引在表中找到記錄，查詢涉及到的字段上若存在索引，則該索引將被列出，但不必定被查詢使用

該列徹底獨立於EXPLAIN輸出所示的表的次序。這意味着在possible_keys中的某些鍵實際上不能按生成的表次序使用。
若是該列是NULL，則沒有相關的索引。在這種狀況下，能夠經過檢查WHERE子句看是否它引用某些列或適合索引的列來提升你的查詢性能。若是是這樣，創造一個適當的索引而且再次用EXPLAIN檢查查詢

• key

key列顯示MySQL實際決定使用的鍵（索引）！！此項強烈建議重點關注

若是沒有選擇索引，鍵是NULL。要想強制MySQL使用或忽視possible_keys列中的索引，在查詢中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。

• key_len

表示索引中使用的字節數，可經過該列計算查詢中使用的索引的長度（key_len顯示的值爲索引字段的最大可能長度，並不是實際使用長度，即key_len是根據表定義計算而得，不是經過表內檢索出的）

不損失精確性的狀況下，長度越短越好

• ref

表示上述表的鏈接匹配條件，即哪些列或常量被用於查找索引列上的值

• rows

表示MySQL根據表統計信息及索引選用狀況，估算的找到所需的記錄所須要讀取的行數

• Extra

該列包含MySQL解決查詢的詳細信息,有如下幾種狀況：

Using where:列數據是從僅僅使用了索引中的信息而沒有讀取實際的行動的表返回的，這發生在對錶的所有的請求列都是同一個索引的部分的時候，表示mysql服務器將在存儲引擎檢索行後再進行過濾

Using temporary：表示MySQL須要使用臨時表來存儲結果集，常見於排序和分組查詢

Using filesort：MySQL中沒法利用索引完成的排序操做稱爲「文件排序」

Using join buffer：改值強調了在獲取鏈接條件時沒有使用索引，而且須要鏈接緩衝區來存儲中間結果。若是出現了這個值，那應該注意，根據查詢的具體狀況可能須要添加索引來改進能。

Impossible where：這個值強調了where語句會致使沒有符合條件的行。

Select tables optimized away：這個值意味着僅經過使用索引，優化器可能僅從聚合函數結果中返回一行

---

總結：• EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響狀況• EXPLAIN不考慮各類Cache• EXPLAIN不能顯示MySQL在執行查詢時所做的優化工做• 部分統計信息是估算的，並不是精確值• EXPALIN只能解釋SELECT操做，其餘操做要重寫爲SELECT後查看執行計劃。