一句話簡單來說，索引的出現其實就是為了提高資料查詢的效率，就像書的目錄一樣。

一本500頁的書，如果你想快速找到其中的某一個知識點，在不借助目錄的情況下，那我估計你可得找一會兒。同樣，對於資料庫的表而言，索引其實就是它的“目錄”。

索引的常見模型

索引的出現是為了提高查詢效率，但是實現索引的方式卻有很多種，所以這裡也就引入了索引模型的概念。可以用於提高讀寫效率的資料結構很多，這裡我先給你介紹三種常見、也比較簡單的資料結構，它們分別是雜湊表、有序陣列和搜尋樹。

下面我主要從使用的角度，為你簡單分析一下這三種模型的區別。

雜湊表是一種以鍵-值（key-value）儲存資料的結構，我們只要輸入待查詢的值即key，就可以找到其對應的值即Value。雜湊的思路很簡單，把值放在數組裡，用一個雜湊函式把key換算成一個確定的位置，然後把value放在陣列的這個位置。

不可避免地，多個key值經過雜湊函式的換算，會出現同一個值的情況。處理這種情況的一種方法是，拉出一個連結串列。

假設，你現在維護著一個身份證資訊和姓名的表，需要根據身份證號查詢對應的名字，這時對應的雜湊索引的示意圖如下所示：

圖中，User2和User4根據身份證號算出來的值都是N，但沒關係，後面還跟了一個連結串列。假設，這時候你要查ID_card_n2對應的名字是什麼，處理步驟就是：首先，將ID_card_n2通過雜湊函式算出N；然後，按順序遍歷，找到User2。

需要注意的是，圖中四個ID_card_n的值並不是遞增的，這樣做的好處是增加新的User時速度會很快，只需要往後追加。但缺點是，因為不是有序的，所以雜湊索引做區間查詢的速度是很慢的。

你可以設想下，如果你現在要找身份證號在[ID_card_X, ID_card_Y]這個區間的所有使用者，就必須全部掃描一遍了。

而有序陣列在等值查詢和範圍查詢場景中的效能就都非常優秀。還是上面這個根據身份證號查名字的例子，如果我們使用有序陣列來實現的話，示意圖如下所示：

這裡我們假設身份證號沒有重複，這個陣列就是按照身份證號遞增的順序儲存的。這時候如果你要查ID_card_n2對應的名字，用二分法就可以快速得到，這個時間複雜度是O(log(N))。

同時很顯然，這個索引結構支援範圍查詢。你要查身份證號在[ID_card_X, ID_card_Y]區間的User，可以先用二分法找到ID_card_X（如果不存在ID_card_X，就找到大於ID_card_X的第一個User），然後向右遍歷，直到查到第一個大於ID_card_Y的身份證號，退出迴圈。

如果僅僅看查詢效率，有序陣列就是最好的資料結構了。但是，在需要更新資料的時候就麻煩了，你往中間插入一個記錄就必須得挪動後面所有的記錄，成本太高。

所以，有序陣列索引只適用於靜態儲存引擎，比如你要儲存的是2017年某個城市的所有人口資訊，這類不會再修改的資料。

二叉搜尋樹也是課本里的經典資料結構了。還是上面根據身份證號查名字的例子，如果我們用二叉搜尋樹來實現的話，示意圖如下所示：

二叉搜尋樹的特點是：每個節點的左兒子小於父節點，父節點又小於右兒子。這樣如果你要查ID_card_n2的話，按照圖中的搜尋順序就是按照UserA -> UserC -> UserF -> User2這個路徑得到。這個時間複雜度是O(log(N))。

在MySQL中，索引是在儲存引擎層實現的，所以並沒有統一的索引標準，即不同儲存引擎的索引的工作方式並不一樣。而即使多個儲存引擎支援同一種類型的索引，其底層的實現也可能不同。由於InnoDB儲存引擎在MySQL資料庫中使用最為廣泛，所以下面我就以InnoDB為例，和你分析一下其中的索引模型。

InnoDB 的索引模型

在InnoDB中，表都是根據主鍵順序以索引的形式存放的，這種儲存方式的表稱為索引組織表。又因為前面我們提到的，InnoDB使用了B+樹索引模型，所以資料都是儲存在B+樹中的。

每一個索引在InnoDB裡面對應一棵B+樹。

假設，我們有一個主鍵列為ID的表，表中有欄位k，並且在k上有索引。

這個表的建表語句是：

mysql> create table T(
id int primary key, 
k int not null, 
name varchar(16),
index (k))engine=InnoDB;

表中R1~R5的(ID,k)值分別為(100,1)、(200,2)、(300,3)、(500,5)和(600,6)，兩棵樹的示例示意圖如下。

從圖中不難看出，根據葉子節點的內容，索引型別分為主鍵索引和非主鍵索引。

主鍵索引的葉子節點存的是整行資料。在InnoDB裡，主鍵索引也被稱為聚簇索引（clustered index）。

非主鍵索引的葉子節點內容是主鍵的值。在InnoDB裡，非主鍵索引也被稱為二級索引（secondary index）。

根據上面的索引結構說明，我們來討論一個問題：基於主鍵索引和普通索引的查詢有什麼區別？

• 如果語句是select * from T where ID=500，即主鍵查詢方式，則只需要搜尋ID這棵B+樹；
• 如果語句是select * from T where k=5，即普通索引查詢方式，則需要先搜尋k索引樹，得到ID的值為500，再到ID索引樹搜尋一次。這個過程稱為回表。

也就是說，基於非主鍵索引的查詢需要多掃描一棵索引樹。因此，我們在應用中應該儘量使用主鍵查詢。

索引維護

B+樹為了維護索引有序性，在插入新值的時候需要做必要的維護。以上面這個圖為例，如果插入新的行ID值為700，則只需要在R5的記錄後面插入一個新記錄。如果新插入的ID值為400，就相對麻煩了，需要邏輯上挪動後面的資料，空出位置。

而更糟的情況是，如果R5所在的資料頁已經滿了，根據B+樹的演算法，這時候需要申請一個新的資料頁，然後挪動部分資料過去。這個過程稱為頁分裂。在這種情況下，效能自然會受影響。

除了效能外，頁分裂操作還影響資料頁的利用率。原本放在一個頁的資料，現在分到兩個頁中，整體空間利用率降低大約50%。

當然有分裂就有合併。當相鄰兩個頁由於刪除了資料，利用率很低之後，會將資料頁做合併。合併的過程，可以認為是分裂過程的逆過程。

自增主鍵是指自增列上定義的主鍵，在建表語句中一般是這麼定義的： NOT NULL PRIMARY KEY AUTO_INCREMENT。

插入新記錄的時候可以不指定ID的值，系統會獲取當前ID最大值加1作為下一條記錄的ID值。

也就是說，自增主鍵的插入資料模式，正符合了我們前面提到的遞增插入的場景。每次插入一條新記錄，都是追加操作，都不涉及到挪動其他記錄，也不會觸發葉子節點的分裂。

而有業務邏輯的欄位做主鍵，則往往不容易保證有序插入，這樣寫資料成本相對較高。

除了考慮效能外，我們還可以從儲存空間的角度來看。假設你的表中確實有一個唯一欄位，比如字串型別的身份證號，那應該用身份證號做主鍵，還是用自增欄位做主鍵呢？

由於每個非主鍵索引的葉子節點上都是主鍵的值。如果用身份證號做主鍵，那麼每個二級索引的葉子節點佔用約20個位元組，而如果用整型做主鍵，則只要4個位元組，如果是長整型（bigint）則是8個位元組。

顯然，主鍵長度越小，普通索引的葉子節點就越小，普通索引佔用的空間也就越小。

所以，從效能和儲存空間方面考量，自增主鍵往往是更合理的選擇。

有沒有什麼場景適合用業務欄位直接做主鍵的呢？還是有的。比如，有些業務的場景需求是這樣的：

1. 只有一個索引；

2. 該索引必須是唯一索引。

你一定看出來了，這就是典型的KV場景。

由於沒有其他索引，所以也就不用考慮其他索引的葉子節點大小的問題。

這時候我們就要優先考慮上一段提到的“儘量使用主鍵查詢”原則，直接將這個索引設定為主鍵，可以避免每次查詢需要搜尋兩棵樹。