B Tree 的效率已經很高了，為什么MySQL 還要對B Tree 進行改良，最終使用了B+Tree 呢？

總體上來說，這個B 樹的改良版本解決的問題比B Tree 更全面。

我們來看一下InnoDB 里面的B+樹的存儲結構：

MySQL 中的B+Tree 有幾個特點：

1、它的關鍵字的數量是跟路數相等的；

2、B+Tree 的根節點和枝節點中都不會存儲數據，只有葉子節點才存儲數據。搜索到關鍵字不會直接返回，會到最后一層的葉子節點。比如我們搜索id=28，雖然在第一層直接命中了，但是全部的數據在葉子節點上面，所以我還要繼續往下搜索，一直到葉子節點。

舉個例子：假設一條記錄是1K，一個葉子節點（一頁）可以存儲16 條記錄。非葉子節點可以存儲多少個指針？

假設索引字段是bigint 類型，長度為8 字節。指針大小在InnoDB 源碼中設置為6 字節，這樣一共14 字節。非葉子節點（一頁）可以存儲16384/14=1170 個這樣的單元（鍵值+指針），代表有1170 個指針。

樹深度為2 的時候， 有1170^2 個葉子節點， 可以存儲的數據為1170*1170*16=21902400。

在查找數據時一次頁的查找代表一次IO，也就是說，一張2000 萬左右的表，查詢數據最多需要訪問3 次磁盤。

所以在InnoDB 中B+ 樹深度一般為1-3 層，它就能滿足千萬級的數據存儲。

3、B+Tree 的每個葉子節點增加了一個指向相鄰葉子節點的指針，它的最后一個數據會指向下一個葉子節點的第一個數據，形成了一個有序鏈表的結構。

4、它是根據左閉右開的區間[ )來檢索數據。

我們來看一下B+Tree 的數據搜尋過程：

1）比如我們要查找28，在根節點就找到了鍵值，但是因為它不是頁子節點，所以會繼續往下搜尋，28 是[28,66)的左閉右開的區間的臨界值，所以會走中間的子節點，然后繼續搜索，它又是[28,34)的左閉右開的區間的臨界值，所以會走左邊的子節點，最后在葉子節點上找到了需要的數據。

2）第二個，如果是范圍查詢，比如要查詢從22 到60 的數據，當找到22 之后，只需要順著節點和指針順序遍歷就可以一次性訪問到所有的數據節點，這樣就極大地提高了區間查詢效率（不需要返回上層父節點重復遍歷查找）。

總結一下，InnoDB 中的B+Tree 的特點：

1)它是B Tree 的變種，B Tree 能解決的問題，它都能解決。B Tree 解決的兩大問題是什么？（每個節點存儲更多關鍵字；路數更多）

2)掃庫、掃表能力更強（如果我們要對表進行全表掃描，只需要遍歷葉子節點就可以了，不需要遍歷整棵B+Tree 拿到所有的數據）

3) B+Tree 的磁盤讀寫能力相對于B Tree 來說更強（根節點和枝節點不保存數據區，所以一個節點可以保存更多的關鍵字，一次磁盤加載的關鍵字更多

4)排序能力更強（因為葉子節點上有下一個數據區的指針，數據形成了鏈表）

5)效率更加穩定（B+Tree 永遠是在葉子節點拿到數據，所以IO 次數是穩定

?

總結

以上是生活随笔為你收集整理的B+树（加强版多路平衡查找树）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。