1. 程式人生 > 實用技巧 >mysql中EXPLAIN 的作用

mysql中EXPLAIN 的作用

(一)id列:

(1)、id 相同執行順序由上到下
mysql> explain  
    -> SELECT*FROM tb_order tb1
    -> LEFT JOIN tb_product tb2 ON tb1.tb_product_id = tb2.id
    -> LEFT JOIN tb_user tb3 ON tb1.tb_user_id = tb3.id;
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref                       | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+
|  1 | SIMPLE      | tb1   | ALL    | NULL          | NULL    | NULL    | NULL                      |    1 | NULL  |
|  1 | SIMPLE      | tb2   | eq_ref | PRIMARY       | PRIMARY | 4       | product.tb1.tb_product_id |    1 | NULL  |
|  1 | SIMPLE      | tb3   | eq_ref | PRIMARY       | PRIMARY | 4       | product.tb1.tb_user_id    |    1 | NULL  |
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+

(2)、如果是子查詢,id序號會自增,id值越大優先順序就越高,越先被執行。
mysql> EXPLAIN
    -> select * from tb_product tb1 where tb1.id = (select tb_product_id from  tb_order tb2 where id = tb2.id =1);
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
|  1 | PRIMARY     | tb1   | const | PRIMARY       | PRIMARY | 4       | const |    1 | NULL        |
|  2 | SUBQUERY    | tb2   | ALL   | NULL          | NULL    | NULL    | NULL  |    1 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
(3)、id 相同與不同,同時存在

mysql> EXPLAIN 
    -> select * from(select * from tb_order tb1 where tb1.id =1) s1,tb_user tb2 where s1.tb_user_id = tb2.id;
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
|  1 | PRIMARY     | <derived2> | system | NULL          | NULL    | NULL    | NULL  |    1 | NULL  |
|  1 | PRIMARY     | tb2        | const  | PRIMARY       | PRIMARY | 4       | const |    1 | NULL  |
|  2 | DERIVED     | tb1        | const  | PRIMARY       | PRIMARY | 4       | const |    1 | NULL  |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
derived2:衍生表   2表示衍生的是id=2的表 tb1

(二)select_type列:資料讀取操作的操作型別

  •   1、SIMPLE:簡單的select 查詢,SQL中不包含子查詢或者UNION。
  •   2、PRIMARY:查詢中包含複雜的子查詢部分,最外層查詢被標記為PRIMARY
  •   3、SUBQUERY:在select 或者WHERE 列表中包含了子查詢
  •   4、DERIVED:在FROM列表中包含的子查詢會被標記為DERIVED(衍生表),MYSQL會遞迴執行這些子查詢,把結果集放到零時表中。
  •   5、UNION:如果第二個SELECT 出現在UNION之後,則被標記位UNION;如果UNION包含在FROM子句的子查詢中,則外層SELECT 將被標記為DERIVED
  •   6、UNION RESULT:從UNION表獲取結果的select

(三)table列:該行資料是關於哪張表

(四)type列:訪問型別 由好到差system > const > eq_ref > ref > range > index > ALL

  •   1、system:表只有一條記錄(等於系統表),這是const型別的特例,平時業務中不會出現。
  •   2、const:通過索引一次查到資料,該型別主要用於比較primary key 或者unique 索引,因為只匹配一行資料,所以很快;如果將主鍵置於WHERE語句後面,Mysql就能將該查詢轉換為一個常量。
  •   3、eq_ref:唯一索引掃描,對於每個索引鍵,表中只有一條記錄與之匹配。常見於主鍵或者唯一索引掃描。
  •   4、ref:非唯一索引掃描,返回匹配某個單獨值得所有行,本質上是一種索引訪問,它返回所有匹配某個單獨值的行,就是說它可能會找到多條符合條件的資料,所以他是查詢與掃描的混合體。
    詳解:這種型別表示mysql會根據特定的演算法快速查詢到某個符合條件的索引,而不是會對索引中每一個數據都進行一 一的掃描判斷,也就是所謂你平常理解的使用索引查詢會更快的取出資料。而要想實現這種查詢,索引卻是有要求的,要實現這種能快速查詢的演算法,索引就要滿足特定的資料結構。簡單說,也就是索引欄位的資料必須是有序的,才能實現這種型別的查詢,才能利用到索引。
    
  •   5、range:只檢索給定範圍的行,使用一個索引來選著行。key列顯示使用了哪個索引。一般在你的WHERE 語句中出現between 、< 、> 、in 等查詢,這種給定範圍掃描比全表掃描要好。因為他只需要開始於索引的某一點,而結束於另一點,不用掃描全部索引。
  •   6、index:FUll Index Scan 掃描遍歷索引樹(index:這種型別表示是mysql會對整個該索引進行掃描。要想用到這種型別的索引,對這個索引並無特別要求,只要是索引,或者某個複合索引的一部分,mysql都可能會採用index型別的方式掃描。但是呢,缺點是效率不高,mysql會從索引中的第一個資料一個個的查詢到最後一個數據,直到找到符合判斷條件的某個索引)。
  •   7、ALL 全表掃描 從磁碟中獲取資料 百萬級別的資料ALL型別的資料儘量優化。

(五)possible_keys列:顯示可能應用在這張表的索引,一個或者多個。查詢涉及到的欄位若存在索引,則該索引將被列出,但不一定被查詢實際使用。

(六)keys列:實際使用到的索引。如果為NULL,則沒有使用索引。查詢中如果使用了覆蓋索引,則該索引僅出現在key列表中。覆蓋索引:select 後的 欄位與我們建立索引的欄位個數一致。

(七)ken_len列:表示索引中使用的位元組數,可通過該列計算查詢中使用的索引長度。在不損失精確性的情況下,長度越短越好。key_len 顯示的值為索引欄位的最大可能長度,並非實際使用長度,即key_len是根據表定義計算而得,不是通過表內檢索出來的。

(八)ref列:顯示索引的哪一列被使用了,如果可能的話,是一個常數。哪些列或常量被用於查詢索引列上的值。

(九) rows列(每張表有多少行被優化器查詢):根據表統計資訊及索引選用的情況,大致估算找到所需記錄需要讀取的行數。

(十)Extra列:擴充套件屬性,但是很重要的資訊。

1、 Using filesort(檔案排序):mysql無法按照表內既定的索引順序進行讀取。
 mysql> explain select order_number from tb_order order by order_money;
+----+-------------+----------+------+---------------+------+---------+------+------+----------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra          |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------+
|  1 | SIMPLE      | tb_order | ALL  | NULL          | NULL | NULL    | NULL |    1 | Using filesort |
+----+-------------+----------+------+---------------+------+---------+------+------+----------------+
row in set (0.00 sec)
說明:order_number是表內的一個唯一索引列,但是order by 沒有使用該索引列排序,所以mysql使用不得不另起一列進行排序。
2、Using temporary:Mysql使用了臨時表儲存中間結果,常見於排序order by 和分組查詢 group by。

mysql> explain select order_number from tb_order group by order_money;
+----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows | Extra                           |
+----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+
|  1 | SIMPLE      | tb_order | ALL  | NULL          | NULL | NULL    | NULL |    1 | Using temporary; Using filesort |
+----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+
row in set (0.00 sec)
3、Using index 表示相應的select 操作使用了覆蓋索引,避免訪問了表的資料行,效率不錯。
如果同時出現Using where ,表明索引被用來執行索引鍵值的查詢。
如果沒有同時出現using where 表明索引用來讀取資料而非執行查詢動作。
mysql> explain select order_number from tb_order group by order_number;
+----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+
| id | select_type | table    | type  | possible_keys      | key                | key_len | ref  | rows | Extra       |
+----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+
|  1 | SIMPLE      | tb_order | index | index_order_number | index_order_number | 99      | NULL |    1 | Using index |
+----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+
row in set (0.00 sec)

4、Using where: WHERE子句用於限制匹配哪些行鍼對下一個表或傳送到客戶端
5、Using join buffer (Block Nested Loop), Using join buffer (Batched Key Access) :表示當前sql使用了連線快取。來自較早聯接的表被部分讀取到聯接緩衝區中,然後使用它們的行從緩衝區中執行與當前表的聯接。
6、impossible where :where 字句 總是false ,mysql 無法獲取資料行。
7、select tables optimized away:
8、distinct:MySQL正在尋找不同的值,因此在找到第一個匹配的行後,它將停止為當前行組合搜尋更多行。
9、Using where with pushed condition: NDB Cluster正在使用條件下推優化來提高在非索引列和常量之間進行直接比較的效率
10、Using sort_union(...),Using union(...),Using intersect(...): 這些指示了特定演算法,該演算法顯示瞭如何針對index_merge聯接型別合併索引掃描 。
11、Using MRR: 使用多範圍讀取優化策略讀取表
12、Using index for group-by: 與Using index表訪問方法類似,Using index for group-by 表示MySQL找到了一個索引,該索引可用於檢索a GROUP BY或 DISTINCT查詢的所有列,而無需對實際表進行任何額外的磁碟訪問。此外,以最有效的方式使用索引,因此對於每個組,僅讀取少數索引條目。
13、Using index condition: 通過訪問索引元組並首先對其進行測試以確定是否讀取完整的錶行來讀取表。這樣,除非有必要,否則索引資訊將用於延遲(“ 下推 ”)整個錶行的讀取。

更多extra引數參見:https://dev.mysql.com/doc/refman/5.6/en/explain-output.html#explain-extra-information

當時做記錄的時候忘記記錄原文連結了,作者看到之後可以私信我,我補上原文連結.