MySQL中索引失效的常見場景與規避方法

前言

之前有看過許多類似的文章內容，提到過一些sql語句的使用不當會導致MySQL的索引失效。還有一些MySQL“軍規”或者規范寫明了某些sql不能這么寫，否則索引失效。

絕大部分的內容筆者是認可的，不過部分舉例中筆者認為用詞太絕對了，并沒有說明其中的原由，很多人不知道為什么。所以筆者絕對再整理一遍MySQL中索引失效的常見場景，并分析其中的原由供大家參考。

當然請記住，explain是一個好習慣！

MySQL索引失效的常見場景

在驗證下面的場景時，請準備足夠多的數據量，因為數據量少時，MySQL的優化器有時會判定全表掃描無傷大雅，就不會命中索引了。

1. where語句中包含or時，可能會導致索引失效

使用or并不是一定會使索引失效，你需要看or左右兩邊的查詢列是否命中相同的索引。

假設USER表中的user_id列有索引，age列沒有索引。

下面這條語句其實是命中索引的（據說是新版本的MySQL才可以，如果你使用的是老版本的MySQL，可以使用explain驗證下）。

select * from `user` where user_id = 1 or user_id = 2;

但是這條語句是無法命中索引的。

select * from `user` where user_id = 1 or age = 20;

假設age列也有索引的話，依然是無法命中索引的。

select * from `user` where user_id = 1 or age = 20;

因此才有建議說，盡量避免使用or語句，可以根據情況盡量使用union all或者in來代替，這兩個語句的執行效率也比or好些。

2. where語句中索引列使用了負向查詢，可能會導致索引失效

負向查詢包括：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等。

某“軍規”中說，使用負向查詢一定會索引失效，筆者查了些文章，有網友對這點進行了反駁并舉證。

其實負向查詢并不絕對會索引失效，這要看MySQL優化器的判斷，全表掃描或者走索引哪個成本低了。

3. 索引字段可以為null，使用is null或is not null時，可能會導致索引失效

其實單個索引字段，使用is null或is not null時，是可以命中索引的，但網友在舉證時說兩個不同索引字段用or連接時，索引就失效了，筆者認為確實索引失效，但這個鍋應該由or來背，屬于第一種場景~~

假設USER表中的user_id列有索引且允許null，age列有索引且允許null。

select * from `user` where user_id is not null or age is not null;

不過某些“軍規”和規范中都有強調，字段要設為not null并提供默認值，是有原因值得參考的。

• null的列使索引/索引統計/值比較都更加復雜，對MySQL來說更難優化。
• null 這種類型MySQL內部需要進行特殊處理，增加數據庫處理記錄的復雜性；同等條件下，表中有較多空字段的時候，數據庫的處理性能會降低很多。
• null值需要更多的存儲空，無論是表還是索引中每行中的null的列都需要額外的空間來標識。
• 對null 的處理時候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in這些操作符號。如：where name!='shenjian'，如果存在name為null值的記錄，查詢結果就不會包含name為null值的記錄。

4. 在索引列上使用內置函數，一定會導致索引失效

比如下面語句中索引列login_time上使用了函數，會索引失效：

select * from `user` where DATE_ADD(login_time, INTERVAL 1 DAY) = 7;

優化建議，盡量在應用程序中進行計算和轉換。

其實還有網友提到的兩種索引失效場景，應該都歸于索引列使用了函數。

4.1 隱式類型轉換導致的索引失效

比如下面語句中索引列user_id為varchar類型，不會命中索引：

select * from `user` where user_id = 12;

這是因為MySQL做了隱式類型轉換，調用函數將user_id做了轉換。

select * from `user` where CAST(user_id AS signed int) = 12;

4.2 隱式字符編碼轉換導致的索引失效

當兩個表之間做關聯查詢時，如果兩個表中關聯的字段字符編碼不一致的話，MySQL可能會調用CONVERT函數，將不同的字符編碼進行隱式轉換從而達到統一。作用到關聯的字段時，就會導致索引失效。

比如下面這個語句，其中d.tradeid字符編碼為utf8，而l.tradeid的字符編碼為utf8mb4。因為utf8mb4是utf8的超集，所以MySQL在做轉換時會用CONVERT將utf8轉為utf8mb4。簡單來看就是CONVERT作用到了d.tradeid上，因此索引失效。

select l.operator from tradelog l , trade_detail d where d.tradeid=l.tradeid and d.id=4;

這種情況一般有兩種解決方案。

方案1: 將關聯字段的字符編碼統一。

方案2: 實在無法統一字符編碼時，手動將CONVERT函數作用到關聯時=的右側，起到字符編碼統一的目的，這里是強制將utf8mb4轉為utf8，當然從超集向子集轉換是有數據截斷風險的。如下：

select d.* from tradelog l , trade_detail d where d.tradeid=CONVERT(l.tradeid USING utf8) and l.id=2; 

5. 對索引列進行運算，一定會導致索引失效

運算如+，-，*，/等，如下：

select * from `user` where age - 1 = 10;

優化的話，要把運算放在值上，或者在應用程序中直接算好，比如：

select * from `user` where age = 10 - 1;

6. like通配符可能會導致索引失效

like查詢以%開頭時，會導致索引失效。解決辦法有兩種：

將%移到后面，如：

select * from `user` where `name` like '李%';

利用覆蓋索引來命中索引。

select name from `user` where `name` like '%李%';

7. 聯合索引中，where中索引列違背最左匹配原則，一定會導致索引失效

當創建一個聯合索引的時候，如(k1,k2,k3)，相當于創建了(k1)、(k1,k2)和(k1,k2,k3)三個索引，這就是最左匹配原則。

比如下面的語句就不會命中索引：

select * from t where k2=2;
select * from t where k3=3;
slect * from t where k2=2 and k3=3;

下面的語句只會命中索引(k1):

slect * from t where k1=1 and k3=3;

8. MySQL優化器的最終選擇，不走索引

上面有提到，即使完全符合索引生效的場景，考慮到實際數據量等原因，最終是否使用索引還要看MySQL優化器的判斷。當然你也可以在sql語句中寫明強制走某個索引。

優化索引的一些建議

• 禁止在更新十分頻繁、區分度不高的屬性上建立索引。
  • 更新會變更B+樹，更新頻繁的字段建立索引會大大降低數據庫性能。
  • “性別”這種區分度不大的屬性，建立索引是沒有什么意義的，不能有效過濾數據，性能與全表掃描類似。
• 建立組合索引，必須把區分度高的字段放在前面。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。

參考

《為什么這些SQL語句邏輯相同，性能卻差異巨大？》

《后端程序員必備：索引失效的十大雜癥》

《58到家數據庫30條軍規解讀》

《MySQL的or/in/union與索引優化 | 架構師之路》