MySQLexplain之possible_keys、key及key_len詳解

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

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

MySQLexplain之possible_keys、key及key_len

possible_keys

顯示可能應(yīng)用在這張表中的索引，一個(gè)或多個(gè)。

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

key

實(shí)際使用的索引。如果為NULL，則沒(méi)有使用索引

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

覆蓋索引：查詢(xún)的字段與所建索引的字段個(gè)數(shù)和順序剛好吻合

key_len

表示索引中使用的字節(jié)數(shù)，可通過(guò)該列計(jì)算查詢(xún)中使用的索引的長(zhǎng)度。

在不損失精確性的情況下，長(zhǎng)度越短越好key_len顯示的值為索引字段的最大可能長(zhǎng)度，并非實(shí)際使用長(zhǎng)度，即key_len是根據(jù)表定義計(jì)算而得，不是通過(guò)表內(nèi)檢索出的

mysql索引possible_keys，key問(wèn)題

explain中有兩個(gè)字段possible_keys，key。

possible_keys：表示可能用到的索引。
key：實(shí)際使用到的索引。

為什么會(huì)有單獨(dú)的兩列？

你的where條件中如果使用到了索引列字段，那么possible_keys會(huì)列出索引字段對(duì)應(yīng)的索引。

mysql可能會(huì)使用到他，但是要看實(shí)際情況，什么是實(shí)際情況？

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

這個(gè)時(shí)候你的搜索條件是查詢(xún)昨天的數(shù)據(jù)，sql類(lèi)似于：

where create_date? > '昨天'?

explain結(jié)果如下：

幾個(gè)關(guān)鍵點(diǎn)：

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

因?yàn)槲覀冎徊樽蛱斓模惶煲粭l數(shù)據(jù)，所以這里是1。

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

然后我們換一個(gè)查詢(xún)方式，查昨天之前的364天的數(shù)據(jù)，sql類(lèi)似如下：

幾個(gè)關(guān)鍵點(diǎn)：

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

因?yàn)槲覀冎徊樽蛱熘暗?，所以?shù)據(jù)量是1041條。

好了，得出的結(jié)論就是possible_keys會(huì)列出你的where條件中可能會(huì)使用到的索引列，但是具體用不到這個(gè)索引，是需要根據(jù)你的實(shí)際情況來(lái)的，如果你的條件，使用到索引和不使用到索引所消耗的效果差不錯(cuò)（磁盤(pán)io，數(shù)據(jù)讀取等）。

舉例來(lái)說(shuō)就是上面的例子，一個(gè)條件查詢(xún)了表中的百分之99的數(shù)據(jù)，即使你的where條件中使用到了索引（并且使用了正確使用索引的姿勢(shì)。），那么優(yōu)化器也會(huì)選擇放棄使用這個(gè)索引，因?yàn)槟闶褂昧诉@個(gè)索引，還會(huì)額外帶來(lái)回表的代碼，那么還不如直接全表掃描。

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