索引失效的十大雜症

背景：最近生產爆出一條慢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加了索引，但是因爲它進行運算，索引直接迷路了。。。山重水複疑無路，算着算着腦瓜疼，索引就真的不認識路了。如圖：

七、（where條件的）索引字段上使用（!= 或者 <>，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和場景，具體分析，而不是按部就班，墨守成規，認定哪個情景一定索引失效等等。

對查詢進行優化，應儘量避免全表掃描，首先應考慮在where以及order by涉及的列上建立索引。
應儘量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：　　select id from t where num/2=100 　　應改爲: 　　select id from t where num=100*2
儘量避免在where子句中對字段進行函數操作,將導致引擎放棄使用索引而進行全表掃描。
不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引
並不是所有的索引對查詢都有效，sql是根據表中的數據來進行查詢優化的，當索引列有大量數據重複時，sql查詢不會去利用索引，如一表中有字段　　sex：male,female幾乎個一半，那麼即使在sex上建立了索引也對查詢效率起不了作用。
索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，　　因爲 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，　　若太多則應考慮一些不常使用到的列上建的索引是否有必要。
儘量使用數字型字段，若只含數值信息的字段儘量不要設計爲字符型，這會降低查詢和連接的性能，並會增加存儲開銷。　　這是因爲引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
mysql查詢只使用一個索引，因此如果where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。　　因此數據庫默認排序可以符合要求的情況下不要使用排序操作，儘量不要包含多個列的排序，如果需要最好給這些列建複合索引。
order by 索引，不起作用的問題（除了主鍵索引之外）：　　1、如果select 只查詢索引字段，order by 索引字段會用到索引，要不然就是全表排列；　　2、如果有where 條件，比如where vtype=1 order by vtype asc . 這樣order by 也會用到索引！

二、四種索引 PRIMARY, INDEX, UNIQUE 這3種是一類 PRIMARY 主鍵。就是唯一且不能爲空。 INDEX 索引，普通的 UNIQUE 唯一索引。不允許有重複。 FULLTEXT 是全文索引，用於在一篇文章中，檢索文本信息的。三、常用SQL優化： 1.優化group by 語句默認情況，MySQL對所有的group by col1,col2進行排序。這與在查詢中指定order by col1, col2類似。如果查詢中包括group by但用戶想要避免排序結果的消耗，則可以使用order by null禁止排序 2.有些情況下，可以使用連接來替代子查詢。因爲使用join，MySQL不需要在內存中創建臨時表。 3.如果想要在含有or的查詢語句中利用索引，則or之間的每個條件列都必須用到索引，如果沒有索引，則應該考慮增加索引 select * from 表名 where 條件1=‘’ or 條件2=‘tt’

索引失效的十大雜症

一、查詢條件包含or，可能導致索引失效

二、如何字段類型是字符串，where時一定用引號括起來，否則索引失效

三、like通配符可能導致索引失效。

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

五、在索引列上使用mysql的內置函數，索引失效。

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

七、（where條件的）索引字段上使用（!= 或者 <>，not in）時，可能會導致索引失效。

八、索引字段上使用is null， is not null，可能導致索引失效。

九、左連接查詢或者右連接查詢查詢關聯的字段編碼格式不一樣，可能導致索引失效。

十、mysql估計使用全表掃描要比使用索引快,則不使用索引。

總結

Spring 中如何控制 Bean 的加載順序？

重磅推出：Milvus Lite 正式上線，幾秒內即可輕鬆搭建 GenAI 應用

vue3 scss style scope 加了無法重寫

VUE3 route 指定打開tab的名稱

如何去掉DedeCMS首頁index.html後綴

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結