MySQLexplain之possible_keys、key及key_len詳解
MySQLexplain之possible_keys、key及key_len
possible_keys
顯示可能應(yīng)用在這張表中的索引,一個(gè)或多個(gè)。
查詢涉及到的字段上若存在索引,則該索引將被列出,但不一定被查詢實(shí)際使用
key
實(shí)際使用的索引。如果為NULL,則沒有使用索引
查詢中若使用了覆蓋索引,則該索引和查詢的selet字段重疊,僅出現(xiàn)在key列表中。
覆蓋索引:查詢的字段與所建索引的字段個(gè)數(shù)和順序剛好吻合

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

mysql索引possible_keys,key問題
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í)候你的搜索條件是查詢昨天的數(shù)據(jù),sql類似于:
where create_date? > '昨天'?
explain結(jié)果如下:

幾個(gè)關(guān)鍵點(diǎn):
type:range 表示你的sql適合范圍查詢possible_keys:表示mysql可能會(huì)用到的索引(也就是create_date字段對(duì)應(yīng)的索引)。key:實(shí)際用到的索引。rows:1 如果查詢優(yōu)化器決定使用全表掃描的方式對(duì)某個(gè)表執(zhí)行查詢時(shí),執(zhí)行計(jì)劃的 rows 列就代表預(yù)計(jì)需要掃描的行數(shù),如果使用索引來執(zhí)行查詢時(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è)查詢方式,查昨天之前的364天的數(shù)據(jù),sql類似如下:

幾個(gè)關(guān)鍵點(diǎn):
type:all 表示你的sql適合范圍查詢possible_keys:表示mysql可能會(huì)用到的索引(也就是create_date字段對(duì)應(yīng)的索引)。key:實(shí)際用到的索引。rows:1041 如果查詢優(yōu)化器決定使用全表掃描的方式對(duì)某個(gè)表執(zhí)行查詢時(shí),執(zhí)行計(jì)劃的 rows 列就代表預(yù)計(jì)需要掃描的行數(shù),如果使用索引來執(zhí)行查詢時(shí),執(zhí)行計(jì)劃的 rows 列就代表預(yù)計(jì)掃描的索引記錄行數(shù)
因?yàn)槲覀冎徊樽蛱熘暗模詳?shù)據(jù)量是1041條。
好了,得出的結(jié)論就是possible_keys會(huì)列出你的where條件中可能會(huì)使用到的索引列,但是具體用不到這個(gè)索引,是需要根據(jù)你的實(shí)際情況來的,如果你的條件,使用到索引和不使用到索引所消耗的效果差不錯(cuò)(磁盤io,數(shù)據(jù)讀取等)。
舉例來說就是上面的例子,一個(gè)條件查詢了表中的百分之99的數(shù)據(jù),即使你的where條件中使用到了索引(并且使用了正確使用索引的姿勢(shì)。),那么優(yōu)化器也會(huì)選擇放棄使用這個(gè)索引,因?yàn)槟闶褂昧诉@個(gè)索引,還會(huì)額外帶來回表的代碼,那么還不如直接全表掃描。
那么他就會(huì)直接放棄使用這個(gè)索引,直接進(jìn)行全表掃描。反之,如果你的數(shù)據(jù)查詢確實(shí)是非常的減少磁盤io這些,那么優(yōu)化器就會(huì)使用你這個(gè)索引。
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
MySQL SELECT同時(shí)UPDATE同一張表問題發(fā)生及解決
例如用統(tǒng)計(jì)數(shù)據(jù)更新表的字段(此時(shí)需要用group子句返回統(tǒng)計(jì)值),從某一條記錄的字段update另一條記錄,而不必使用非標(biāo)準(zhǔn)的語句,等等感興趣的朋友可以參考下哈2013-03-03
Navicat for MySQL 11注冊(cè)碼\激活碼匯總
Navicat for MySQL注冊(cè)碼用來激活 Navicat for MySQL 軟件,只要擁有 Navicat 注冊(cè)碼就能激活相應(yīng)的 Navicat 產(chǎn)品。這篇文章主要介紹了Navicat for MySQL 11注冊(cè)碼\激活碼匯總,需要的朋友可以參考下2020-11-11
MySQL中datetime時(shí)間字段的四舍五入操作
這是由一則生產(chǎn)環(huán)境問題引出的MySQL對(duì)于datetime時(shí)間類型字段中毫秒的處理的深究,這篇文章主要給大家介紹了關(guān)于MySQL中datetime時(shí)間字段的四舍五入操作的相關(guān)資料,需要的朋友可以參考下2021-09-09
mysql導(dǎo)出查詢結(jié)果到csv的實(shí)現(xiàn)方法
下面小編就為大家?guī)硪黄猰ysql導(dǎo)出查詢結(jié)果到csv的實(shí)現(xiàn)方法。小編覺得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-04-04
MySQL: mysql is not running but lock exists 的解決方法
下面可以參考下面的方法步驟解決。最后查到一個(gè)網(wǎng)友說可能和log文件有關(guān),于是將log文件給移除了,再重啟MySQL終于OK了2009-06-06
MySQL觸發(fā)器學(xué)習(xí)總結(jié)
創(chuàng)建觸發(fā)器,當(dāng)往order表中添加記錄是,更新goods表,大家可以看下語句即可2012-09-09

