前情提要

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

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

我就說了下面一句話：

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

出現(xiàn)的情況

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

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

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

原因

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

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

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

• 當查詢條件中包含了某個表的主鍵或者非空的唯一索引列
• 該列的判定條件為等值條件
• 目標值的類型與該列的類型一致
• 目標值為一個確定的常量

而我們的這張表user_info的這個查詢語句剛好符合這4個條件，原因：

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

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

3、phone是字符串類型，'13800138000’也是字符串類型

4、13800138000是一個確定的常量

總結(jié)

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

最新評論