共計 1133 個字符，預計需要花費 3 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關為什么 MySQL 偶爾會選錯索引，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

在此之前，我做過不少 ToC 的項目，在 ToC 的應用場景中，業務一般都是比較簡單，基本上沒有多少復雜的查詢 (基本上，只要建立用戶 ID 為索引，就能夠大大提升查詢效率了。) 這兩年，也逐漸接觸到一些 ToB 的業務，發現 ToB 的業務，真的是比 ToC 的要復雜一些。舉個簡單的例子，ToB 應用中，最痛苦的事情就是組織架構，原本查詢一個人的數據，可能變成查詢一個小組，一個部門，甚至是一個分公司的數據。

不僅如此，由于不同職級的員工的查詢權限可能不一樣。查詢條件比 ToC 場景中復雜得多，所以有時候一張表，會建立好多個不同的索引。后時候我們就會發現，怎么查詢莫名其妙就變得很慢了。按道理說，如果命中了我們想要的索引，應該很快才對。

于是，我們就對 Sql 語句進行分析，發現 Mysql 使用的是另外一個索引，但是在這個業務下，使用另外一個索引會得到更好的結果，為什么 Mysql 會選錯索引呢? 很顯然，存儲很難會去理解業務的實際情況，Mysql 也需要一定的算法才能評估出索引的優劣，Mysql 是這樣進行評分的。

Mysql 對索引的評分的首要原則，就是索引的差異度最大，舉個例子，假如是一個小學生信息查詢系統，我們以出生日期建立索引，那么大概就有 365* 7 個不同的值，假如我們以學生的性別作為索引，那么基本上就只有 2 個不同的值了，假如一個查詢條件同時包含出生日期跟性別，那么 Mysql 必然優先選基數更大的作為索引，也就是出生日期作為索引。

那但是，Mysql 實際上并不理解什么是出生日期，什么是性別，他們是判斷哪一個基數更大的呢? 非常簡單，把索引掃一遍不就知道結果了么? 我們只要在索引樹上掃一遍，就能夠知道不同的 Key 有多少個。但是，假如我們的數據越來越多，每次都把所有的索引樹都掃描一遍并不現實。基于大多數的互聯網應用都是讀多寫少的，Mysql 會把索引的評分記錄一段時間，但是，每次觸發重新評估的時候，仍要花費不少的時間。

Mysql 采用抽樣調查的方式，隨機從各個索引樹上面取一定的頁數，通過統計這些頁數對索引進行評估。現在回到我們現實的開發中，不知道你有沒有遇到過這樣的問題，一些異常狀態占總數量非常少，例如退貨退款的訂單只占總訂單的少數，但是你使用 Mysql 查詢的時候卻很命中這個索引。就是因為在 Mysql 評估分數的時候，大多數時候都會覺得這個索引上面不同數據量很少，所以打了低分。

上述就是丸趣 TV 小編為大家分享的為什么 MySQL 偶爾會選錯索引了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。