mysql索引優化及explain關鍵字段解釋

sql優化最低標準 ：

一、不超過6層嵌套

二、每一個嵌套內不超過3個join 

三、最大檢索行數不超過10億行

1、explain關鍵字解釋

        

一、id

    MySQL QueryOptimizer 選定的執行計劃中查詢的序列號,表示查詢中執行select 子句或操做表的順序。id 值越大優先級越高,越先被執行。id 相同,執行順序由上至下。

二、select_type

    (1) SIMPLE

        簡單的 select 查詢(不使用 union 及子查詢)。

    (2) PRIMARY

        最外層的 select 查詢。

        若是兩表存在則查詢，則外層的表操做爲PRIMARY，內層（子查詢）的操做爲SUBQUERY。

        若是兩表作union，則外層的表操做爲PRIMARY，內層（union後面）的操做爲union。

       

    (3)SUBQUERY/ DEPENDENT SUBQUERY

       SUBQUERY:子查詢中首個SELECT（若是有多個子查詢存在），不依賴於外層的表。除from子句中包含的子查詢外，其餘地方出現的子查詢均可能是subquery。

       DEPENDENT SUBQUERY：子查詢中首個select（若是有多個子查詢存在） ，但依賴於外層的表。

      

    (4)UNION/ DEPENDENT UNION

      UNION：union操做中，處於內層（第二個或隨後的） select 查詢,不依賴於外部查詢的結果集。

      DEPENDENT UNION：union操做中，處於內層的select 查詢,但內層的SELECT語句與外層的SELECT語句有依賴關係。

      UNION RESULT：union操做的結果，id值一般爲NULL  。

     

   (5)UNCACHEABLE SUBQUERY/UNCACHEABLE UNION

     MATERIALIZED：被物化的子查詢

     UNCACHEABLE SUBQUERY：對於外層的主表，子查詢不可被物化，每次都須要計算（耗時操做）。

     UNCACHEABLE UNION：union操做中，內層的不可被物化的子查詢。

   (6)DERIVED

     被驅動的SELECT子查詢，用於 from 子句裏有子查詢的狀況。 MySQL 會遞歸執行這些子查詢, 把結果放在臨時表裏（from字句中出現的子查詢，也叫作派生表，其餘數據庫中可能叫作內聯視圖或嵌套select）。

     

三、table 

     輸出行所引用的表。顯示的查詢表名，若是查詢使用了別名，那麼這裏顯示的是別名，若是不涉及對數據表的操做，那麼這顯示爲null，若是顯示爲尖括號括起來的<derived N>就表示這個是臨時表，後邊的N就是執行計劃中的id，表示結果來自於這個查詢產生。若是是尖括號括起來的<union M,N>，與<derived N>相似，也是一個臨時表，表示這個結果來自於union查詢的id爲M,N的結果集。

 四、type

     從優到差的順序以下:（紅色標識的是常見的級別。）除了all以外，其餘的type均可以使用到索引，除了index_merge以外，其餘的type只能夠用到一個索引。

System-->const-->eq_ref-->ref--> fulltext-->ref_or_null-->index_merge-->unique_subquery-->index_subquery-->range-->index-->all.

各自的含義以下:

（1）system

        表僅有一行(=系統表)。這是 const 鏈接類型的一個特例。表中只有一行數據或者是空表，且只能用於myisam和memory表。若是是Innodb引擎表，type列在這個狀況一般都是all或者index。

（2）const

       const 用於用常數值比較 PRIMARY KEY 時。使用惟一索引或者主鍵，返回記錄必定是1行記錄的等值where條件時，一般type是const。其餘數據庫也叫作惟一索引掃描。當查詢的表僅有一行時,使用 System。

 

    （3）eq_ref

      出如今要鏈接這個表的查詢計劃中，從前面的表中，對每個記錄的聯合都從表中讀取一個記錄，驅動表只返回一行數據，且這行數據是第二個表的主鍵或者惟一索引，且必須爲not null，它在查詢使用了索引爲主鍵或惟一鍵的所有時使用。惟一索引和主鍵是多列時，只有全部的列都用做比較時纔會出現eq_ref。

      例如：a left join b時，聯結條件必須爲b表的主鍵或是惟一索引。若是主鍵是聯合索引，則鏈接順序與主鍵一致。dim_company_app的主鍵爲（company,merchant_mo）

       

（4）ref

     不像eq_ref那樣要求鏈接順序，也沒有主鍵和惟一索引的要求，只要使用相等條件檢索時就可能出現，常見與輔助索引的等值查找。或者多列主鍵、惟一索引中，使用第一個列以外的列做爲等值查找也會出現，總之，返回數據不惟一的等值查找就可能出現.

        

（5）fulltext

        全文索引檢索，要注意，全文索引的優先級很高，若全文索引和普通索引同時存在時，mysql無論代價，優先選擇使用全文索引。

（6）ref_or_null

        如同 ref, 可是 MySQL 必須在初次查找的結果裏找出 null 條目,而後進行二次查找。與ref方法相比，只是增長了null值的比較，實際用的很少。

（7）index_merge

       說明索引合併優化被使用了。表示查詢使用了兩個以上的索引，最後取交集或者並集，常見and ，or的條件使用了不一樣的索引，官方排序這個在ref_or_null以後，可是實際上因爲要讀取多個索引，性能可能大部分時間都不如range。

（8）unique_subquery

       用於where中的in形式子查詢，子查詢返回不重複值惟一值。在某些 IN 查詢中使用此種類型,而不是常規的 ref:valueIN (SELECT primary_key FROM single_table WHERE some_expr)。

（9）index_subquery

       用於in形式子查詢使用到了輔助索引或者in常數列表，子查詢可能返回重複值，可使用索引將子查詢去重。在 某 些 IN 查 詢 中 使 用 此 種 類 型 , 與unique_subquery 相似,可是查詢的是非惟一性索引。

（10）range

      索引範圍掃描，常見於使用>,<,is null,between ,in ,like等運算符的查詢中。只檢索給定範圍的行,使用一個索引來選擇行。key列顯示使用了哪一個索引。當使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操做符,用常量比較關鍵字列時,可使用 range。

        

（11）index

      索引全表掃描，把索引從頭至尾掃一遍，常見於使用索引列就能夠處理不須要讀取數據文件的查詢、可使用索引排序或者分組的查詢。全表掃描,只是掃描表的時候按照索引次序進行而不是行。主要優勢就是避免了排序, 可是開銷仍然很是大。

（12）all

全表掃描數據文件，而後在server層進行過濾返回符合要求的記錄。最壞的狀況,從頭至尾全表掃描。

五、possible keys

     指出能在該表中使用哪些索引有助於查詢，查詢可能使用到的索引都會在這裏列出來。若是爲空,說明沒有可用的索引。

 六、key

     實際從 possible_key 選擇使用的索引，若是爲 NULL,則沒有使用索引。select_type爲index_merge時，這裏可能出現兩個以上的索引，其餘的select_type這裏只會出現一個。不多的狀況下,MYSQL 會選擇優化不足的索引。這種狀況下,能夠在 SELECT語句中使用 USE INDEX (indexname)來強制使用一個索引或者用IGNORE INDEX(indexname)來強制 MYSQL 忽略索引。

七、key_len

     用於處理查詢的索引長度，在不損失精確性的狀況 下,長度越短越好。若是是單列索引，那就整個索引長度算進去，若是是多列索引，那麼查詢不必定都能使用到全部的列，具體使用到了多少個列的索引，這裏就會計算進去，沒有使用到的列，這裏不會計算進去。留意下這個列的值，算一下你的多列索引總長度就知道有沒有使用到全部的列了。要注意，mysql的ICP特性使用到的索引不會計入其中。另外，key_len只計算where條件用到的索引長度，而排序和分組就算用到了索引，也不會計算到key_len中。

 八、ref

     顯示索引的哪一列被使用了。若是是使用的常數等值查詢，這裏會顯示const，若是是鏈接查詢，被驅動表的執行計劃這裏會顯示驅動表的關聯字段，若是是條件使用了表達式或者函數，或者條件列發生了內部隱式轉換，這裏可能顯示爲func。

九、rows

      認爲必須檢查的用來返回請求數據的行數，即須要掃描的行數。

十、extra

       這個列能夠顯示的信息很是多，有幾十種，經常使用的有下面幾種。其中，若是出現Using filesort、Using temporary 兩項意味着不能使用索引,效率會受到重大影響。應儘量對此進行優化。

（1）distinct：在select部分使用了distinc關鍵字。

（2）no tables used：不帶from字句的查詢或者From dual查詢。

（3）使用not in()形式子查詢或not exists運算符的鏈接查詢，這種叫作反鏈接。即，通常鏈接查詢是先查詢內表，再查詢外表，反鏈接就是先查詢外表，再查詢內表。

（4）using filesort：排序時沒法使用到索引時，就會出現這個。常見於order by和group by語句中。沒有辦法利用現有索引進行排序，須要額外排序，建議：根據排序須要，建立相應合適的索引。

（5）using index：查詢時不須要回表查詢，直接經過索引就能夠獲取查詢的數據。利用覆蓋索引，無需回表便可取得結果數據，這種結果是好的。

（6）using join buffer（block nested loop），using join buffer（batched key accss）：5.6.x以後的版本優化關聯查詢的BNL，BKA特性。主要是減小內表的循環數量以及比較順序地掃描查詢。

（7）using sort_union，using_union，using intersect，using sort_intersection：

using intersect：表示使用and的各個索引的條件時，該信息表示是從處理結果獲取交集；

using union：表示使用or鏈接各個使用索引的條件時，該信息表示從處理結果獲取並集；

using sort_union和using sort_intersection：與前面兩個對應的相似，只是他們是出如今用and和or查詢信息量大時，先查詢主鍵，而後進行排序合併後，才能讀取記錄並返回。

（8）using temporary：表示使用了臨時表存儲中間結果。臨時表能夠是內存臨時表和磁盤臨時表，執行計劃中看不出來，須要查看status變量，used_tmp_table，used_tmp_disk_table才能看出來。須要用臨時表存儲結果集，一般是由於group by的列上沒有索引。也有多是由於同時有group by和order by，但group by和order by的列又不同

（9）using where：表示存儲引擎返回的記錄並非全部的都知足查詢條件，須要在server層進行過濾。查詢條件中分爲限制條件和檢查條件，5.6以前，存儲引擎只能根據限制條件掃描數據並返回，而後server層根據檢查條件進行過濾再返回真正符合查詢的數據。5.6.x以後支持ICP特性，能夠把檢查條件也下推到存儲引擎層，不符合檢查條件和限制條件的數據，直接不讀取，這樣就大大減小了存儲引擎掃描的記錄數量。extra列顯示using index condition

（10）firstmatch(tb_name)：5.6.x開始引入的優化子查詢的新特性之一，常見於where字句含有in()類型的子查詢。若是內表的數據量比較大，就可能出現這個

（11）loosescan(m..n)：5.6.x以後引入的優化子查詢的新特性之一，在in()類型的子查詢中，子查詢返回的可能有重複記錄時，就可能出現這個

除了這些以外，還有不少查詢數據字典庫，執行計劃過程當中就發現不可能存在結果的一些提示信息。

 

總結：其中重要的幾個就是 key、type 、rows、extra，其中key爲null時，說明沒有使用到索引，須要調整索引。type爲all的地方,須要進行優化.通常須要達到 ref、eq_ref 級別，範圍查找須要達到 range。extra有Using filesort、Using temporary 的必定須要優化，根據rows能夠直觀看出優化結果。

 

以上內容轉載並整理自：

https://www.cnblogs.com/xiaoboluo768/p/5400990.html

https://blog.csdn.net/HXNLYW/article/details/82979088

https://www.cnblogs.com/danhuangpai/p/8475458.htm