mysql - explain

explain + 查詢語句，會返回mysql處理sql語句的分析結果

 

EXPLAIN 
SELECT t1.t_id FROM table1 t1 WHERE t1.t_id = (SELECT MIN(t_id) FROM table2)
UNION 
SELECT t3.t_id FROM table3 t3

 

結果：

  

 

 1.id: 表的讀取順序

表明優先級，數字越大，先被加載

 

2.select_type ： 數據讀取操做的操做類型

simple  簡單查詢，沒有複雜結構

primary  有子查詢時，最外層的是primary

subquery   子查詢

derived      衍生的，通常會出如今from 後面跟select 時（嵌套查詢）。

union                   union查詢後面的table會被標記爲union

union result         union 查詢的結果

 

3. table：   表名

 

4. type：訪問類型

性能從好到差依次是：

1. system（系統類型：單行數據，const的特例，等於系統表，基本見不到）   = =不過我測試的時候就算一條數據也達不到system。。。

2. const   （常量類型：利用 主鍵，或者union index）

3. eq_ref （惟一索引 （union index） 掃描，只有一條記錄匹配。）

4. ref       （單行非惟一索引 （index） 掃描）

5. range  （索引或者主鍵給定範圍的查詢 好比  select * from table1 where id > 1）

6. index  （全索引掃描）

7. ALL    （全表掃描）

正常狀況下，儘可能達到 ref 或者 range 級別已經能夠知足大部分需求。

 

5. possible_keys 

 顯示理論上可能應用在此次查詢的索引（有可能possible_keys是null，而key有值，好比 select id from table1，查詢的字段正好是索引，理論上不須要用到索引，可是mysql運行時用到了索引）

 

6. key 

 mysql實際查詢時使用到的索引（null則爲沒有使用索引）

 

7. key_len 

使用到的索引的最大長度（只是mysql推測，不是實際長度），越小越好。

通常條件越多，key_len越大 。

 

8. ref 

索引被用來匹配了那些內容。cont是指常量 好比 id = 1 這種  

若是有用到其餘列則會顯示匹配用到的列

 

 

 

9. rows 

mysql估算的有多少行須要被掃描。（越小越好）

 

10. Extra

額外信息：

1. using filesort：使用了外部索引排序，mysql沒法利用索引完成排序（說明在此次查詢中包含了索引字段，可是索引沒有被實際用到，最好優化一下）

2. using temporary： mysql完成查詢時用到了臨時表。

這兩種最多見狀況，是group by 後的字段順序和內容跟複合索引不一致。

建一個表和索引用來測試：

CREATE TABLE index_test(
   t_id INT PRIMARY KEY,
   key1 INT,
   key2 INT,
   key3 INT,
   key4 INT
);

INSERT INTO index_test VALUES(1,1,1,1,1);
INSERT INTO index_test VALUES(2,1,2,3,4);
INSERT INTO index_test VALUES(3,4,1,2,3);
INSERT INTO index_test VALUES(4,3,4,1,2);
INSERT INTO index_test VALUES(5,2,3,4,1);


CREATE INDEX index_key1_key2_key3_key4 ON index_test(key1,key2,key3,key4);

 

 

 緣由：由於複合索引按照key1，key2，key3，key4的順序進行了排序，直接用key3時，mysql雖然想用索引可是沒有辦法找到

好比 key1 = 4, key2 = 1, key3 = 2 在索引中在 key1 = 3, key2 = 4, key3 = 1 前面，mysql就沒法利用索引快速定位 key3位置。

 

優化辦法： 把索引順序和字段可以對應上

 

 

 

3. using index： slq語句使用了覆蓋索引，說明此次查詢的結果是經過索引直接讀取而不是查詢到結果再讀取結果所在行，效率很高。

好比key1，key2，key3，key4 是複合索引，我查key1，key2，key3，key4的值，mysql直接從這個索引表裏讀取key1，key2，key3，key4的數據， 而不是先定位 index_test 表中符合條件的列，而後從這個表中讀取數據。

 

4. using where： 索引被用於查找（沒有直接定位，而是在索引的基礎上進行了查找）。

 

當查找的列不全是索引時，就不會有using index了

 

5. using join buffer： join太多，使用了緩存。 

這時能夠考慮 配置文件的join buffer調大一點。

 

6. impossible where： where錯誤，好比下面這種，key1 = 1 and key1 = 2，不可能

 

 

 

7.select tables optimized away：  沒有group by時，mysql對count，min，max作了優化。 只是用來講明。

 

8.   distinct： distinct時第一個結果就符合要求後再也不尋找其餘相同值。 只是用來講明。

 

extra主要做用： 針對1,2種狀況，對sql語句進行優化。

 

 

 

11. filtered:   5.5 新加的列， rows掃描的結果中mysql估算有%多少被實際用到

當使用非索引做爲查詢條件時，遍歷了5行，只發現了一個符合結果，只有20%的掃描結果被使用。因此這個值大一些比較好。