為什麼Mysql 資料庫表中有索引還是查詢慢

前言：

問題分析:

在進行資料庫查詢的時候，我們都知道索引可以加快資料查詢的效率。但是在實際的業務場景下，經常會遇到即使在表中增加了索引，但是同樣還是會出現資料查詢慢的問題。這就需要具體分析資料查詢慢的具體原因到底是什麼了。

首先需要進行確認的就是 SQL 語句中對應的條件查詢中欄位有沒有建立索引。雖然說表中已經有索引，但是不一定 SQL 語句中的查詢欄位有建立索引，所以第一步應該進行 SQL 中的欄位索引確認。如果沒有建立對應的索引可以先嚐試下建立索引再進行查詢。如果已經有了索引，查詢的欄位也是索引欄位，那麼就要考慮下是不是出現了索引失效的情況。下面我們再具體分析下，看看在哪些場景下會出現索引失效的情況。

索引失效場景：

在分析索引失效場景之前，我們必須要清楚索引結構的特點是什麼。

我們再來看下 Mysql 資料庫索引的結構特點：

本文以 user_info 這張表來作為分析的基礎，在 user_info 這張表上，我們分別建立了 idx_name 以及 idx_phone 二級索引以及 idx_age_address 聯合索引。

1、欄位型別不匹配導致的索引失效

進行 SQL 資料查詢的時候，where 條件欄位型別與實際表中欄位型別不匹配的時候，Mysql 會進行隱式的資料型別轉換，而型別轉換會使用到內建函數，導致在進行資料查詢的時候並沒有使用索引。我們可以使用 explain 命令檢視 sql 語句。可以看的出來在 key 欄中，對應的值為 null，說明並沒有使用索引進行查詢。

但是如果在按照 phone_number 欄位為字串型別進行查詢的時候，Mysql 沒有進行隱式的型別轉換，所以最終還是走了索引。

2、被索引欄位使用了表示式計算

在 where 中條件使用了條件表示式的時候，資料表中的索引就失效了，實際是因為 Mysql 需要將索引欄位取出來之後再進行表示式的條件判斷，因而進行了全表掃描，導致索引失效。

3、被索引欄位使用了內建函數

索引欄位實際上是依賴於整個 B+索引樹的遍歷，而索引樹的遍歷又依賴於索引樹底層葉子節點的有序性。索引儲存的是索引列的原始值，如果經過函數計算，Mysql 的直譯器無法判斷計算後的索引在原來的索引樹上是否可以被索引到，因此它就直接放棄使用索引查詢了。

4、like 使用了 %X 模糊匹配

使用左模糊匹配以及左右模糊匹配都會導致索引失效，但是使用右模糊匹配，還是可以走索引查詢的。

由於 B+樹按照索引值進行排序的，實際是按照最左字首進行比較，而使用了 %作為最左字首，Mysql 無法判斷其有序性，因此只能進行全表掃描查詢。

5、索引欄位不是聯合索引欄位的最左欄位

如果資料庫表中有聯合索引的話，我們在 SQL 查詢語句中使用的索引欄位又不是聯合索引的最左欄位，那麼就會導致索引失效。

實際上在 Mysql 中的索引檢索是遵循最左匹配原則的，同時 B+索引樹的葉子節點的有序性也是建立在最左匹配原則之上，而上述的 4、5 兩種情況實際違反了最左匹配原則，因此 Mysql 執行器則無法使用對應的索引進行檢查查詢。

6、or 分割的條件

如果 or 左邊的條件存在索引，而右邊的條件沒有索引，不走索引
因為 OR 的含義就是兩個只要滿足一個即可，因此只有一個條件列進行了索引是沒有意義的，只要有條件列沒有進行索引，就會進行全表掃描，因此索引的條件列也會失效。

7、in、not in 可能會導致索引失效

這裡需要說明的是使用 in 以及 not in 走不走索引，實際和 Mysql 的版本以及表中的資料量有關係，在 8.0 之後的版本是走索引的。

注：此處加了地址的索引。

總結

本文總結了幾種索引失效的場景，希望在大家平時專案開發時遇到類似的問題可以有對應的問題排查方向。導致索引失效的場景歸結起來實際就是在索引使用上面存在瑕疵最終導致了索引失效的情況，這就像我們小時候打拳皇 97 一樣，遙感和按鈕的組合如果姿勢不對，就沒辦法放出我們希望的大招。總之需要一些經驗的積累，同時在寫完 SQL 的時候可以進行執行檢查，避免線上上出現索引失效的問題。

到此這篇關於為什麼Mysql 資料庫表中有索引還是查詢慢的文章就介紹到這了,更多相關Mysql 查詢慢原理內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！