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

[[323773]]

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

于是，我們就對Sql語句進(jìn)行分析，發(fā)現(xiàn)Mysql使用的是另外一個索引，但是在這個業(yè)務(wù)下，使用另外一個索引會得到更好的結(jié)果，為什么Mysql會選錯索引呢?很顯然，存儲很難會去理解業(yè)務(wù)的實(shí)際情況，Mysql也需要一定的算法才能評估出索引的優(yōu)劣，Mysql是這樣進(jìn)行評分的。

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

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

Mysql采用抽樣調(diào)查的方式，隨機(jī)從各個索引樹上面取一定的頁數(shù)，通過統(tǒng)計這些頁數(shù)對索引進(jìn)行評估。現(xiàn)在回到我們現(xiàn)實(shí)的開發(fā)中，不知道你有沒有遇到過這樣的問題，一些異常狀態(tài)占總數(shù)量非常少，例如退貨退款的訂單只占總訂單的少數(shù)，但是你使用Mysql查詢的時候卻很命中這個索引。就是因?yàn)樵贛ysql評估分?jǐn)?shù)的時候，大多數(shù)時候都會覺得這個索引上面不同數(shù)據(jù)量很少，所以打了低分。所以，如果你有這種特殊的業(yè)務(wù)場景，最好進(jìn)行指定索引。

好了，今天我們簡單介紹了mysql的索引選擇，不知道對你是否有所啟發(fā)，歡迎大家關(guān)注我，共同學(xué)習(xí)，共同進(jìn)步。大家的支持是我繼續(xù)嘮嗑的動力。