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

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

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

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

1、它的關鍵字的數(shù)量是跟路數(shù)相等的；

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

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

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

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

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

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

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

4、它是根據(jù)左閉右開的區(qū)間[ )來檢索數(shù)據(jù)。

我們來看一下B+Tree 的數(shù)據(jù)搜尋過程：

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

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

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

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

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

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

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

5)效率更加穩(wěn)定（B+Tree 永遠是在葉子節(jié)點拿到數(shù)據(jù)，所以IO 次數(shù)是穩(wěn)定

?

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。