MySQLexplain之possible_keys、key及key_len詳解

更新時間：2023年08月07日 16:34:40 作者：昔拉天使

這篇文章主要介紹了MySQLexplain之possible_keys、key及key_len的用法,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

MySQLexplain之possible_keys、key及key_len

顯示可能應用在這張表中的索引，一個或多個。

查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢實際使用

實際使用的索引。如果為NULL，則沒有使用索引

查詢中若使用了覆蓋索引，則該索引和查詢的selet字段重疊，僅出現在key列表中。

覆蓋索引：查詢的字段與所建索引的字段個數和順序剛好吻合

表示索引中使用的字節(jié)數，可通過該列計算查詢中使用的索引的長度。

在不損失精確性的情況下，長度越短越好key_len顯示的值為索引字段的最大可能長度，并非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的

explain中有兩個字段possible_keys，key。

為什么會有單獨的兩列？

你的where條件中如果使用到了索引列字段，那么possible_keys會列出索引字段對應的索引。

mysql可能會使用到他，但是要看實際情況，什么是實際情況？

打個比方，如果你有一個按照日期創(chuàng)建的索引列，每天插入一條數據，插入了一年，那么就有365條數據。

這個時候你的搜索條件是查詢昨天的數據，sql類似于：

where create_date? > '昨天'?

explain結果如下：

幾個關鍵點：

type：range 表示你的sql適合范圍查詢
possible_keys：表示mysql可能會用到的索引（也就是create_date字段對應的索引）。
key：實際用到的索引。
rows：1 如果查詢優(yōu)化器決定使用全表掃描的方式對某個表執(zhí)行查詢時，執(zhí)行計劃的 rows 列就代表預計需要掃描的行數，如果使用索引來執(zhí)行查詢時，執(zhí)行計劃的 rows 列就代表預計掃描的索引記錄行數

因為我們只查昨天的，一天一條數據，所以這里是1。

extra：Using index condition; 表示有些搜索條件中雖然出現了索引列，但卻不能使用到索引（這個是不是和possible_keys沖突了？有待驗證）

然后我們換一個查詢方式，查昨天之前的364天的數據，sql類似如下：

幾個關鍵點：

type：all 表示你的sql適合范圍查詢
possible_keys：表示mysql可能會用到的索引（也就是create_date字段對應的索引）。
key：實際用到的索引。
rows：1041 如果查詢優(yōu)化器決定使用全表掃描的方式對某個表執(zhí)行查詢時，執(zhí)行計劃的 rows 列就代表預計需要掃描的行數，如果使用索引來執(zhí)行查詢時，執(zhí)行計劃的 rows 列就代表預計掃描的索引記錄行數

因為我們只查昨天之前的，所以數據量是1041條。

好了，得出的結論就是possible_keys會列出你的where條件中可能會使用到的索引列，但是具體用不到這個索引，是需要根據你的實際情況來的，如果你的條件，使用到索引和不使用到索引所消耗的效果差不錯（磁盤io，數據讀取等）。

舉例來說就是上面的例子，一個條件查詢了表中的百分之99的數據，即使你的where條件中使用到了索引（并且使用了正確使用索引的姿勢。），那么優(yōu)化器也會選擇放棄使用這個索引，因為你使用了這個索引，還會額外帶來回表的代碼，那么還不如直接全表掃描。

那么他就會直接放棄使用這個索引，直接進行全表掃描。反之，如果你的數據查詢確實是非常的減少磁盤io這些，那么優(yōu)化器就會使用你這個索引。