數(shù)據(jù)庫為什么要建索引？

在滿足語句需求的情況下，盡量少的訪問資源是數(shù)據(jù)庫設(shè)計(jì)的重要原則，這和執(zhí)行的 SQL 有直接的關(guān)系，索引問題又是 SQL 問題中出現(xiàn)頻率最高的，常見的索引問題包括：無索引（失效）、隱式轉(zhuǎn)換。1. SQL 執(zhí)行流程看一個(gè)問題，在下面這個(gè)表 T 中，如果我要執(zhí)行 需要執(zhí)行幾次樹的搜索操作，會(huì)掃描多少行？

這分別是 ID 字段索引樹、k 字段索引樹。

這條 SQL 語句的執(zhí)行流程：

1. 在 k 索引樹上找到 k=3，獲得 ID=3002. 回表到 ID 索引樹查找 ID=300 的記錄，對應(yīng) R33. 在 k 索引樹找到下一個(gè)值 k=5，ID=5004. 再回到 ID 索引樹找到對應(yīng) ID=500 的 R4

5. 在 k 索引樹去下一個(gè)值 k=6，不符合條件，循環(huán)結(jié)束

這個(gè)過程讀取了 k 索引樹的三條記錄，回表了兩次。因?yàn)椴樵兘Y(jié)果所需要的數(shù)據(jù)只在主鍵索引上有，所以必須得回表。所以，我們該如何通過優(yōu)化索引，來避免回表呢？2. 常見索引優(yōu)化2.1 覆蓋索引覆蓋索引，換言之就是索引要覆蓋我們的查詢請求，無需回表。

如果執(zhí)行的語句是 ，這樣的話因?yàn)?ID 的值在 k 索引樹上，就不需要回表了。

覆蓋索引可以減少樹的搜索次數(shù)，顯著提升查詢性能，是常用的性能優(yōu)化手段。

但是，維護(hù)索引是有代價(jià)的，所以在建立冗余索引來支持覆蓋索引時(shí)要權(quán)衡利弊。

2.2 最左前綴原則

B+ 樹的數(shù)據(jù)項(xiàng)是復(fù)合的數(shù)據(jù)結(jié)構(gòu)，比如 的時(shí)候，B+ 樹是按照從左到右的順序來建立搜索樹的，當(dāng) 這樣的數(shù)據(jù)來檢索的時(shí)候，B+ 樹會(huì)優(yōu)先比較 name 來確定下一步的檢索方向，如果 name 相同再依次比較 sex 和 age，最后得到檢索的數(shù)據(jù)。

可以清楚的看到，A1 使用 tl 索引，A2 進(jìn)行了全表掃描，雖然 A2 的兩個(gè)條件都在 tl 索引中出現(xiàn)，但是沒有使用到 name 列，不符合最左前綴原則，無法使用索引。所以在建立聯(lián)合索引的時(shí)候，如何安排索引內(nèi)的字段排序是關(guān)鍵。評估標(biāo)準(zhǔn)是索引的復(fù)用能力，因?yàn)橹С肿钭笄熬Y，所以當(dāng)建立（a，b）這個(gè)聯(lián)合索引之后，就不需要給 a 單獨(dú)建立索引。原則上，如果通過調(diào)整順序，可以少維護(hù)一個(gè)索引，那么這個(gè)順序往往就是需要優(yōu)先考慮采用的。上面這個(gè)例子中，如果查詢條件里只有 b，就是沒法利用（a，b）這個(gè)聯(lián)合索引的，這時(shí)候就不得不維護(hù)另一個(gè)索引，也就是說要同時(shí)維護(hù)（a，b）、（b）兩個(gè)索引。這樣的話，就需要考慮空間占用了，比如，name 和 age 的聯(lián)合索引，name 字段比 age 字段占用空間大，所以創(chuàng)建（name，age）聯(lián)合索引和（age）索引占用空間是要小于（age，name）、(name）索引的。

2.3 索引下推

以人員表的聯(lián)合索引（name, age）為例。如果現(xiàn)在有一個(gè)需求：檢索出表中“名字第一個(gè)字是張，而且年齡是26歲的所有男性”。那么，SQL 語句是這么寫的

通過最左前綴索引規(guī)則，會(huì)找到 ID1，然后需要判斷其他條件是否滿足在 MySQL 5.6 之前，只能從 ID1 開始一個(gè)個(gè)回表。到主鍵索引上找出數(shù)據(jù)行，再對比字段值。而 MySQL 5.6 引入的索引下推優(yōu)化(index condition pushdown)，可以在索引遍歷過程中，對索引中包含的字段先做判斷，直接過濾掉不滿足條件的記錄，減少回表次數(shù)。這樣，減少了回表次數(shù)和之后再次過濾的工作量，明顯提高檢索速度。

2.4 隱式類型轉(zhuǎn)化

隱式類型轉(zhuǎn)化主要原因是，表結(jié)構(gòu)中指定的數(shù)據(jù)類型與傳入的數(shù)據(jù)類型不同，導(dǎo)致索引無法使用。所以有兩種方案：

修改表結(jié)構(gòu)，修改字段數(shù)據(jù)類型。

修改應(yīng)用，將應(yīng)用中傳入的字符類型改為與表結(jié)構(gòu)相同類型。

3. 為什么會(huì)選錯(cuò)索引3.1 優(yōu)化器選擇索引是優(yōu)化器的工作，其目的是找到一個(gè)最優(yōu)的執(zhí)行方案，用最小的代價(jià)去執(zhí)行語句。在數(shù)據(jù)庫中，掃描行數(shù)是影響執(zhí)行代價(jià)的因素之一。掃描的行數(shù)越少，意味著訪問磁盤數(shù)據(jù)的次數(shù)越少，消耗的 CPU 資源越少。當(dāng)然，掃描行數(shù)并不是唯一的判斷標(biāo)準(zhǔn)，優(yōu)化器還會(huì)結(jié)合是否使用臨時(shí)表、是否排序等因素進(jìn)行綜合判斷。

3.2 掃描行數(shù)

MySQL 在真正開始執(zhí)行語句之前，并不能精確的知道滿足這個(gè)條件的記錄有多少條，只能通過索引的區(qū)分度來判斷。顯然，一個(gè)索引上不同的值越多，索引的區(qū)分度就越好，而一個(gè)索引上不同值的個(gè)數(shù)我們稱為“基數(shù)”，也就是說，這個(gè)基數(shù)越大，索引的區(qū)分度越好。

MySQL 使用采樣統(tǒng)計(jì)方法來估算基數(shù)：采樣統(tǒng)計(jì)的時(shí)候，InnoDB 默認(rèn)會(huì)選擇 N 個(gè)數(shù)據(jù)頁，統(tǒng)計(jì)這些頁面上的不同值，得到一個(gè)平均值，然后乘以這個(gè)索引的頁面數(shù)，就得到了這個(gè)索引的基數(shù)。而數(shù)據(jù)表是會(huì)持續(xù)更新的，索引統(tǒng)計(jì)信息也不會(huì)固定不變。所以，當(dāng)變更的數(shù)據(jù)行數(shù)超過 1/M 的時(shí)候，會(huì)自動(dòng)觸發(fā)重新做一次索引統(tǒng)計(jì)。

在 MySQL 中，有兩種存儲(chǔ)索引統(tǒng)計(jì)的方式，可以通過設(shè)置參數(shù) innodb_stats_persistent 的值來選擇：

on 表示統(tǒng)計(jì)信息會(huì)持久化存儲(chǔ)。默認(rèn) N = 20，M = 10。

off 表示統(tǒng)計(jì)信息只存儲(chǔ)在內(nèi)存中。默認(rèn) N = 8，M = 16。

由于是采樣統(tǒng)計(jì)，所以不管 N 是 20 還是 8，這個(gè)基數(shù)都很容易不準(zhǔn)確。所以，冤有頭債有主，MySQL 選錯(cuò)索引，還得歸咎到?jīng)]能準(zhǔn)確地判斷出掃描行數(shù)。

可以用 來重新統(tǒng)計(jì)索引信息，進(jìn)行修正。

3.3 索引選擇異常和處理1. 采用 force index 強(qiáng)行選擇一個(gè)索引。2. 可以考慮修改語句，引導(dǎo) MySQL 使用我們期望的索引。3. 有些場景下，可以新建一個(gè)更合適的索引，來提供給優(yōu)化器做選擇，或刪掉誤用的索引。