後端程式設計師必備：索引失效的十大雜症
背景
最近生產爆出一條慢sql，原因是用了or和!=，導致索引失效。於是，總結了索引失效的十大雜症，希望對大家有幫助，加油。
一、查詢條件包含or，可能導致索引失效
新建一個user表，它有一個普通索引userId，結構如下：
CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `userId` int(11) NOT NULL, `age` int(11) NOT NULL, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `idx_userId` (`userId`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
- 執行一條查詢sql，它是會走索引的，如下圖所示：
- 把or條件+沒有索引的age加上，並不會走索引，如圖：
分析&結論：
- 對於or+沒有索引的age這種情況，假設它走了userId的索引，但是走到age查詢條件時，它還得全表掃描，也就是需要三步過程： 全表掃描+索引掃描+合併
- 如果它一開始就走全表掃描，直接一遍掃描就完事。
- mysql是有優化器的，處於效率與成本，遇到or條件，索引可能失效，看起來也合情合理。
注意: 如果or條件的列都加了索引，索引可能會走的，大家可以自己試一試。
二、如何欄位型別是字串，where時一定用引號括起來，否則索引失效
假設demo表結構如下：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` varchar(32) NOT NULL,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_userId` (`userId`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;userId為字串型別，是B+樹的普通索引，如果查詢條件傳了一個數字過去，它是不走索引的，如圖所示：
如果給數字加上'',也就是傳一個字串呢，當然是走索引，如下圖：
分析與結論：
為什麼第一條語句未加單引號就不走索引了呢？
這是因為不加單引號時，是字串跟數字的比較，它們型別不匹配，MySQL會做隱式的型別轉換，把它們轉換為浮點數再做比較。
三、like萬用字元可能導致索引失效。
並不是用了like萬用字元，索引一定失效，而是like查詢是以%開頭，才會導致索引失效。
表結構：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` varchar(32) NOT NULL,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_userId` (`userId`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;like查詢以%開頭，索引失效，如圖：
把%放後面，發現索引還是正常走的，如下：
把%加回來，改為只查索引的欄位（覆蓋索引），發現還是走索引，驚不驚喜，意不意外
結論：
like查詢以%開頭，會導致索引失效。可以有兩種方式優化：
- 使用覆蓋索引
- 把%放後面
附: 索引包含所有滿足查詢需要的資料的索引，稱為覆蓋索引(Covering Index)。
四、聯合索引，查詢時的條件列不是聯合索引中的第一個列，索引失效。
表結構：（有一個聯合索引idx_userid_age，userId在前，age在後）
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` int(11) NOT NULL,
`age` int(11) DEFAULT NULL,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_userid_age` (`userId`,`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;在聯合索引中，查詢條件滿足最左匹配原則時，索引是正常生效的。請看demo：
如果條件列不是聯合索引中的第一個列，索引失效，如下：
分析與結論：
- 當我們建立一個聯合索引的時候，如(k1,k2,k3)，相當於建立了（k1）、(k1,k2)和(k1,k2,k3)三個索引，這就是最左匹配原則。
- 聯合索引不滿足最左原則，索引一般會失效，但是這個還跟Mysql優化器有關的。
五、在索引列上使用mysql的內建函式，索引失效。
表結構：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` varchar(32) NOT NULL,
`loginTime` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_userId` (`userId`) USING BTREE,
KEY `idx_login_time` (`loginTime`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;雖然loginTime加了索引，但是因為使用了mysql的內建函式Date_ADD()，索引直接GG，如圖：
六、對索引列運算（如，+、-、*、/），索引失效。
表結構：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` varchar(32) NOT NULL,
`age` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;雖然age加了索引，但是因為它進行運算，索引直接迷路了。。。
如圖：
七、索引欄位上使用（！= 或者 < >，not in）時，可能會導致索引失效。
表結構：
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`userId` int(11) NOT NULL,
`age` int(11) DEFAULT NULL,
`name` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;雖然age加了索引，但是使用了！= 或者 < >，not in這些時，索引如同虛設。如下：
八、索引欄位上使用is null， is not null，可能導致索引失效。
表結構:
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`card` varchar(255) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE,
KEY `idx_card` (`card`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;單個name欄位加上索引，並查詢name為非空的語句，其實會走索引的，如下:
單個card欄位加上索引，並查詢name為非空的語句，其實會走索引的，如下:
但是它兩用or連線起來，索引就失效了，如下：
九、左連線查詢或者右連線查詢查詢關聯的欄位編碼格式不一樣，可能導致索引失效。
新建兩個表，一個user，一個user_job
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) CHARACTER SET utf8mb4 DEFAULT NULL,
`age` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
CREATE TABLE `user_job` (
`id` int(11) NOT NULL,
`userId` int(11) NOT NULL,
`job` varchar(255) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
user 表的name欄位編碼是utf8mb4，而user_job表的name欄位編碼為utf8。
執行左外連線查詢,user_job表還是走全表掃描，如下：
如果把它們改為name欄位編碼一致，還是會走索引。
十、mysql估計使用全表掃描要比使用索引快,則不使用索引。
當表的索引被查詢，會使用最好的索引，除非優化器使用全表掃描更有效。優化器優化成全表掃描取決與使用最好索引查出來的資料是否超過表的30%的資料。
不要給'性別'等增加索引。如果某個資料列裡包含了均是"0/1"或“Y/N”等值，即包含著許多重複的值，就算為它建立了索引，索引效果不會太好，還可能導致全表掃描。
Mysql出於效率與成本考慮，估算全表掃描與使用索引，哪個執行快。這跟它的優化器有關，來看一下它的邏輯架構圖吧（圖片來源網上）
總結
總結了索引失效的十大雜症，在這裡來個首尾呼應吧，分析一下我們生產的那條慢sql。
模擬的表結構與肇事sql如下：
CREATE TABLE `user_session` (
`user_id` varchar(32) CHARACTER SET utf8mb4 NOT NULL,
`device_id` varchar(64) NOT NULL,
`status` varchar(2) NOT NULL,
`create_time` datetime NOT NULL,
`update_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`user_id`,`device_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;explain
update user_session set status =1
where (`user_id` = '1' and `device_id`!='2')
or (`user_id` != '1' and `device_id`='2')分析：
- 執行的sql，使用了
or條件，因為組合主鍵(user_id,device_id)，看起來像是每一列都加了索引，索引會生效。 - 但是出現
!=,可能導致索引失效。也就是or+!=兩大綜合症，導致了慢更新sql。
解決方案:
那麼，怎麼解決呢？我們是把or條件拆掉，分成兩條執行。同時給device_id加一個普通索引。
最後，總結了索引失效的十大雜症，希望大家在工作學習中，參考這十大雜症，多點結合執行計劃expain和場景，具體分析 ，而不是按部就班，墨守成規，認定哪個情景一定索引失效。
個人公眾號
- 如果你是個愛學習的好孩子，可以關注我公眾號，一起學習討論。
- 如果你覺得本文有哪些不正確的地方，可以評論，也可以關注我公眾號，私聊我，大家一起學習進步哈。