標籤:
在日常工作中,我們會有時會開慢查詢去記錄一些執行時間比較久的SQL語句,找出這些SQL語句並不意味著完事了,些時我們常常用到explain這個命令來查看一個這些SQL語句的執行計畫,查看該SQL語句有沒有使用上了索引,有沒有做全表掃描,這都可以通過explain命令來查看。所以我們深入瞭解MySQL的基於開銷的最佳化器,還可以獲得很多可能被最佳化器考慮到的存取原則的細節,以及當運行SQL語句時哪種策略預計會被最佳化器採用。(QEP:sql產生一個執行計畫query Execution plan)
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 |+----+-------------+---------+------+---------------+------+---------+------+------+-------+1 row in set (0.03 sec)
expain出來的資訊有10列,分別是id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面對這些欄位出現的可能進行解釋:
一、 id
我的理解是SQL執行的順序的標識,SQL從大到小的執行
1. id相同時,執行順序由上至下
2. 如果是子查詢,id的序號會遞增,id值越大優先順序越高,越先被執行
3.id如果相同,可以認為是一組,從上往下順序執行;在所有組中,id值越大,優先順序越高,越先執行
二、select_type
示查詢中每個select子句的類型
(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
顯示這一行的資料是關於哪張表的,有時不是真實的表名字,看到的是derivedx(x是個數字,我的理解是第幾步執行的結果)
mysql> explain select * from (select * from ( select * from t1 where id=2602) a) b;+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+| 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | || 2 | DERIVED | <derived3> | system | NULL | NULL | NULL | NULL | 1 | || 3 | DERIVED | t1 | const | PRIMARY,idx_t1_id | PRIMARY | 4 | | 1 | |+----+-------------+------------+--------+-------------------+---------+---------+------+------+-------+
四、type
表示MySQL在表中找到所需行的方式,又稱“訪問類型”。
常用的類型有: 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後查看執行計畫。
參考資料:http://dev.mysql.com/doc/refman/5.5/en/explain-output.html
http://www.cnitblog.com/aliyiyi08/archive/2008/09/09/48878.html
http://www.cnblogs.com/gomysql/p/3720123.html
MySQL Explain詳解