前情提要

上午有同事突然找我，向我反饋說(shuō)在對(duì)MySQL中的語(yǔ)句進(jìn)行explain解析的時(shí)候，explain的結(jié)果中table、type、possible_keys、key等關(guān)鍵性字段都是空的，什么信息都得不到，而當(dāng)把其中一個(gè)字段phone，類(lèi)型是varchar的單引號(hào)去掉了之后，也就是說(shuō)把where phone='13800138000' 改為where phone=13800138000之后，再執(zhí)行explain就能得到explain的關(guān)鍵性字段的結(jié)果了。

這個(gè)就讓我很納悶，不合常理啊，字段的隱式轉(zhuǎn)換正常來(lái)說(shuō)這種情況應(yīng)該會(huì)導(dǎo)致索引失效才對(duì)啊，現(xiàn)在竟然是反之生效，刷新了我們的認(rèn)知。

我就說(shuō)了下面一句話：

一個(gè)不合常理的現(xiàn)象往往都是由于一個(gè)不起眼的或者平時(shí)被我們忽略的點(diǎn)所造成的

出現(xiàn)的情況

這種非常理所能解釋通的現(xiàn)象，引起了我的好奇心。

從上圖中看到Extra：Impossible WHERE noticed after reading const tables，字面上的意思是：讀取const tables表之后，沒(méi)有發(fā)現(xiàn)匹配的行。

其實(shí)，這個(gè)跟MySQL的版本有關(guān)，在 MySQL 5.7.17 下的執(zhí)行結(jié)果中可以發(fā)現(xiàn)同樣的表結(jié)構(gòu)、同樣的數(shù)據(jù)、同樣的查詢(xún)語(yǔ)句，Extra 中的顯示的內(nèi)容為“no matching row in const table”，這句話理解起來(lái)就容易多了。

原因

產(chǎn)生“ Impossible WHERE noticed after reading const tables”的原因是這樣的，MySQL在 EXPLAIN 之前會(huì)優(yōu)先根據(jù)這一條件查找出對(duì)應(yīng)的記錄，并用記錄的實(shí)際值替換查詢(xún)中所有使用到的該表屬性。

這是因?yàn)闈M足以下四個(gè)條件時(shí)，就會(huì)使得針對(duì)該表的查詢(xún)最多只能產(chǎn)生一條命中結(jié)果，在該表無(wú)法命中數(shù)據(jù)的情況下就會(huì)提示“在 const table 表中沒(méi)有找到匹配的行”，而這個(gè) “const table”就指的是滿足下面四個(gè)條件的表。

這是 MySQL 的一個(gè)優(yōu)化策略。

• 當(dāng)查詢(xún)條件中包含了某個(gè)表的主鍵或者非空的唯一索引列
• 該列的判定條件為等值條件
• 目標(biāo)值的類(lèi)型與該列的類(lèi)型一致
• 目標(biāo)值為一個(gè)確定的常量

而我們的這張表user_info的這個(gè)查詢(xún)語(yǔ)句剛好符合這4個(gè)條件，原因：

1、phone是非空的唯一索引列；

2、phone= '13800138000’是等值條件

3、phone是字符串類(lèi)型，'13800138000’也是字符串類(lèi)型

4、13800138000是一個(gè)確定的常量

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論