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

[[323773]]

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

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

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

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

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

好了，今天我們簡單介紹了mysql的索引選擇，不知道對你是否有所啟發，歡迎大家關注我，共同學習，共同進步。大家的支持是我繼續嘮嗑的動力。