面試題：MySQL索引爲何用B+樹？

前言

講到索引，第一反應確定是能提升查詢效率。例如書的目錄，想要查找某一章節，會先從目錄中定位。若是沒有目錄，那麼就須要將全部內容都看一遍才能找到。

索引的設計對程序的性能相當重要，若索引太少，對查詢性能受影響；而若是索引太多，則會影響增/改/刪等的性能。

知識點

MySQL中通常支持如下幾種常見的索引：

• B+樹索引
• 全文索引
• 哈希索引

咱們今天重點來說下B+樹索引，以及爲何要用B+樹來做爲索引的數據結構。

B+樹索引並不能直接找到具體的行，只是找到被查找行所在的頁，而後DB經過把整頁讀入內存，再在內存中查找。

重溫數據結構

1.1 哈希結構

若有 三、一、二、十、九、0、四、6這8個數據，創建如圖1-1所示哈希索引。

• 直接查詢：如今要從8個數中查找6這條記錄，只須要計算6的哈希值，即可快速定位記錄，時間複雜度爲O(1)。

• 範圍查詢：若是要進行範圍查詢（大於4的數據），那這個索引就徹底沒用了。

圖1-1 哈希索引

1.2 二叉樹查找樹

二叉樹是一種經典的數據結構，要求左子樹小於根節點，右子樹大於根節點。

若有 三、一、二、十、九、0、四、6這8個數據，創建如圖1-2所示二分查找樹。

• 直接查詢：假設查找鍵值爲6的記錄，先找到根4，4<6，所以查找4的右子樹，找到9；9大於6，所以查找9的左子樹；一共查找3次。但若是順序查找，則須要查找8次（位於最後）。

• 範圍查詢：若是須要查找大於4的數據，則遍歷4的右子樹就好了。

圖1-2 二叉查找樹

1.3 平衡二叉樹（AVL樹）

按照二叉查找樹的定義，它是能夠任意的構造，一樣是這些數字，能夠按照圖1-3-1的方式來創建二叉查找樹。一樣查找數據6，須要查找5次。

圖1-3-1 性能較差的二叉查找樹

所以爲了最大性能地構造一個二叉查找樹，須要它是平衡的，即平衡二叉樹。

平衡二叉樹定義：首先符合二叉查找樹的定義，另外任何節點的兩個子樹高度最大差爲1。

平衡二叉樹的查詢速度是很快的，可是有缺點：

1. 維護樹的代價是很是大，在進行插入或更新時，常常會須要屢次左旋或右旋來維持平衡。如圖1-3-2所示
2. 數據量多的時候，樹會很高，須要屢次I/O操做。
3. 在進行範圍查找時，假設查找>=3，先找到3，而後須要查找到3的父節點，而後遍歷父節點的右子樹。

圖1-3-2 平衡二叉樹AVL

1.4 B+ 樹

在B+樹中，全部記錄節點存放在葉子節點上，且是順序存放，由各葉子節點指針進行鏈接。若是從最左邊的葉子節點開始順序遍歷，能獲得全部鍵值的順序排序。

若有 三、一、二、十、九、0、四、6這8個數據，可創建如圖1-4-1所示高度爲2的B+樹。

圖1-4-1 高度爲2的B+樹

在進行更新時，B+樹一樣須要相似二叉樹的旋轉操做。舉例，假設新增一個7，那能夠直接填充到四、6的後面。若是再添加8，那麼就須要進行旋轉了，感覺下面的B+樹旋轉過程。

圖1-4-2 高度爲3的B+樹

採用B+樹的索引結構優勢：

1. B+樹的高度通常爲2-4層，因此查找記錄時最多隻須要2-4次IO，相對二叉平衡樹已經大大下降了。
2. 範圍查找時，能經過葉子節點的指針獲取數據。例如查找大於等於3的數據，當在葉子節點中查到3時，經過3的尾指針便能獲取全部數據，而不須要再像二叉樹同樣再獲取到3的父節點。

未完待續…

若是想要實時關注更新的文章以及分享的乾貨，能夠關注個人公衆號