後端程序員必備：索引失效的十大雜症

背景

最近生產爆出一條慢sql，緣由是用了or和!=，致使索引失效。因而，總結了索引失效的十大雜症，但願對你們有幫助，加油。

1、查詢條件包含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;

1. 執行一條查詢sql，它是會走索引的，以下圖所示：
2. 把or條件+沒有索引的age加上，並不會走索引，如圖：

分析&結論：

• 對於or+沒有索引的age這種狀況，假設它走了userId的索引，可是走到age查詢條件時，它還得全表掃描，也就是須要三步過程： 全表掃描+索引掃描+合併
• 若是它一開始就走全表掃描，直接一遍掃描就完事。
• mysql是有優化器的，處於效率與成本，遇到or條件，索引可能失效，看起來也合情合理。

注意: 若是or條件的列都加了索引，索引可能會走的，你們能夠本身試一試。

2、如何字段類型是字符串，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會作隱式的類型轉換，把它們轉換爲浮點數再作比較。

3、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)。

4、聯合索引，查詢時的條件列不是聯合索引中的第一個列，索引失效。

表結構：（有一個聯合索引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優化器有關的。

5、在索引列上使用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，如圖：

6、對索引列運算（如，+、-、*、/），索引失效。

表結構：

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加了索引，可是由於它進行運算，索引直接迷路了。。。 如圖：

7、索引字段上使用（！= 或者 < >，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這些時，索引如同虛設。以下：

8、索引字段上使用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鏈接起來，索引就失效了，以下：

9、左鏈接查詢或者右鏈接查詢查詢關聯的字段編碼格式不同，可能致使索引失效。

新建兩個表，一個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字段編碼一致，仍是會走索引。

10、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和場景，具體分析 ，而不是循序漸進，墨守成規，認定哪一個情景必定索引失效。

我的公衆號

• 若是你是個愛學習的好孩子，能夠關注我公衆號，一塊兒學習討論。
• 若是你以爲本文有哪些不正確的地方，能夠評論，也能夠關注我公衆號，私聊我，你們一塊兒學習進步哈。