?有位粉絲面試高開的時候被問到，為什么SQL語句命中索引比不命中索引要快？雖然自己也知道答案，但被問到的瞬間，就不知道如何組織語言了。今天，我給大家深度分析一下。

1.索引的作用

想象一下，現在有一本包含幾十萬字的字典，有幾百頁厚，同時里面的字是無序排列的。如果在不使用目錄的情況下，我們如何從字典中找出需要的字來呢？毫無疑問，我們只能一頁一頁地翻，顯然，這是一項反人類的的工作。

我們必然想的是先看目錄，然后，找到相關的字或者偏旁，然后，找到對應的頁碼再去查找想要找的文字，這樣，效率就大大提高了。而事實上，目錄就是一種索引，我們說的數據庫索引思想和目錄的思想一脈相承。

數據庫索引最主要的作用就是幫助我們快速檢索到想要的數據，從而不至于每次查詢都做全局掃描。

假設不使用任何算法的情況下，我們要查詢10萬條記錄中的某一條，在最壞的情況下需要遍歷10萬次。

但如果使用二分查找算法，則只需要進行log2 20000次，也就是14.287712次即可。這意味著我們只需對排序后的值進行14次搜索，就可以使用二分查找到想要的唯一值，常見的索引數據結構有B樹和B+樹。

下面我們，以MySQL的InnoDB引擎為例，分析一下索引的工作原理。

2.索引執行原理

我們知道MySQL的InnoDB引擎采用的是B+樹數據結構，當我們去執行SELECT語句查詢數據的時候，InnoDB需要從磁盤上去讀取數據，而這個過程會涉及到磁盤 以及磁盤的隨機IO ，我們來看這么一個圖：

系統會把數據的邏輯地址傳給磁盤，磁盤控制線路按照尋址邏輯把邏輯地址翻譯成物理地址。也就是確定要讀取的數據在哪個磁道、哪個扇區。為了讀取這個扇區的數據，需要把磁頭放在這個扇區上面，為了實現這樣一個點，磁盤會不斷地去旋轉。把目標扇區旋轉到磁頭下面，使得磁頭能夠去找到對應的磁道。這里還會涉及到尋道的時間以及旋轉時間的一個損耗。很明顯磁盤IO這個過程的性能開銷是非常大的，尤其是查詢的數據量比較多的情況下。

所以InnotDB里面，干脆對存儲在磁盤上的數據建立一個索引，然后把索引數據以及索引列對應的磁盤地址以B+樹的方式進行存儲。來看這么一個圖：

當我們需要查找目標數據的時候，根據索引從B+樹中去查找目標數據就行了。由于B+樹的子樹比較多，所以，只需要較少次數的磁盤IO就能夠查找到目標數據。

至于B+樹的數據結構，在這里就不分析了。大家可以去我的個人主頁看往期視頻有講到。

3.索引的弊端

雖然，使用索引能減少磁盤IO次數，提高查詢效率，但是，索引也不能建立太多。如果一個表中所有字段的索引很大，也會導致性能 l下降。想象一下，如果一個索引和一個表一樣長，那么它將再次成為一個需要檢查的開銷。這就好比字典的目錄非常詳細，但是其長度已經和所有的文字一樣長，這個時候目錄本身的效率就大大下降了。

那索引有弊端嗎？肯定是有的，索引可以提高查詢讀取性能，而它會將降低寫入性能。當有索引時，如果更改一條記錄，或者在數據庫中插入一條新的記錄，它將執行兩個寫入操作（一個操作是寫入記錄本身，另一個操作是將更新索引）。

因此，在定義索引時，必須牢記以下幾點：

• 索引表中的每個字段將降低寫入性能。
• 建議使用表中的唯一值為字段編制索引。
• 在關系數據庫中充當外鍵的字段必須建立索引，因為它們有助于跨多個表進行復雜查詢。
• 索引還使用磁盤空間，因此在選擇要索引的字段時要小心。