在算法邏輯上，二叉樹的查找效率和比較次數都是最小的，但是在實際問題中，還要考慮磁盤IO.

數據庫索引是存儲在磁盤上的，當數據量比較大時，索引可能幾個G。

當我們利用索引查詢的時候，不能將整個索引全部加載到內存中，能做的只能是逐一加載每一個磁盤頁，這里的磁盤頁對應索引樹的節點。

二叉查找數、平衡二叉樹、紅黑樹是典型的二叉查找數結構，其查找的時間復雜度為O(log2N)與樹的深度有關，所以降低樹的深度自然能提高查找效率。

在實際場景中：大規模數據存儲中，實現索引查詢這樣一個實際場景下，樹節點存儲的元素數量是有限的(如果元素數量非常多的話，查找退化成節點內部的線性查找了)，這樣導致二叉查找樹結構由于樹的深度過大而造成磁盤I/O讀寫過于頻繁，進而降低查詢效率低下，所以就思考如何降低樹的深度(當然不能減少查詢的數據量)，一個基本的想法是：采用多叉樹結構

B樹和B+樹是平衡的多路查找樹

一、B樹

簡單來說：B樹是一種多路平衡查找樹，它的每一個節點最多包含k個孩子，k也稱為階樹。

k的大小取決于磁盤頁的大小

概念：B樹和平衡二叉樹稍有不同的是B樹屬于多叉樹又名平衡多路查找樹(查找路徑不只兩個)，數據庫索引技術里大量使用者B樹和B+樹的數據結構，讓我們來看看他有什么特點;

規則：

(1)排序方式：所有節點關鍵字是按遞增次序排列，并遵循左小右大原則；

(2)子節點數：非葉節點的子節點數>1，且<=M ，且M>=2，空樹除外(注：M階代表一個樹節點最多有多少個查找路徑，M=M路,當M=2則是2叉樹,M=3則是3叉)；

(3)關鍵字數：枝節點的關鍵字數量大于等于ceil(m/2)-1個且小于等于M-1個(注：ceil()是個朝正無窮方向取整的函數 如ceil(1.1)結果為2);

(4)所有葉子節點均在同一層、葉子節點除了包含了關鍵字和關鍵字記錄的指針外也有指向其子節點的指針只不過其指針地址都為null對應下圖最后一層節點的空格子;

用途：

文件系統和部分數據庫索引，比如著名的非關系型數據庫MongoDB

最后我們用一個圖和一個實際的例子來理解B樹(這里為了理解方便我就直接用實際字母的大小來排列C>B>A)

高度每下降一級，即讀取一次磁盤(一次I/O)；當一個磁盤頁數據讀取到內存，對一個節點內數據查找，速度很快，幾乎可以忽略。所以樹的高度足夠低，I/O次數足夠少，就能提升性能。

B樹的查詢流程：

如上圖我要從上圖中找到E字母，查找流程如下

(1)獲取根節點的關鍵字進行比較，當前根節點關鍵字為M，E

(2)拿到關鍵字D和G，D

(3)拿到E和F，因為E=E 所以直接返回關鍵字和指針信息(如果樹結構里面沒有包含所要查找的節點則返回null)；

考題：M階B-樹中含有N個關鍵字，最大深度為：

至于為什么不能葉節點不能存儲關鍵字，查看如下原因：

葉子結點是不存在的，指向這些結點的指針為空，引入葉子結點的目的是為了方便分析B-樹的查找性能

一棵3階B-樹中含有2047個關鍵字,包含葉結點層,該樹的最大深度為(12)

二、B+樹

B+樹的性能比B樹更高

1.與B樹區別：

①有n棵子樹的節點含有n個關鍵碼

②所有的葉節點中包含了全部關鍵碼的信息，以及指向含有這些關鍵碼記錄的指針，且葉子節點本身依關鍵字大小自小而大順序連接

③所有的非終端節點可以看成是索引部分，節點中僅含有其子樹根節點中最大(小)的關鍵字

對③理解

衛星數據：索引元素所指向的數據記錄，比如數據庫中的某一行。在B樹中，無論是中間節點還是葉子節點都有衛星數據。

而B+樹中，只有葉子節點帶有衛星數據，其余中間節點僅僅是索引，沒有任何數據關聯

在B+樹中，通常有兩個頭指針，一個指向根節點，另一個指向關鍵字最小的葉節點。因此，可以對B+數進行兩種查找運算：一種是從最小關鍵字開始順序查找，另一種是從根節點進行隨機查找。

查找過程與B樹類似，但是有兩點不同(也是查找效率更優的原因)

①B+樹的中間節點，沒有衛星數據，所以同樣大小的磁盤頁可以容納更多的節點元素【?“更矮胖”，查詢時IO次數更少】

②B+樹必須查找到葉子節點，而B樹只要找到匹配元素即可，無論匹配元素處于中間節點還是葉子節點

因此B樹查找性能并不穩定(最好，只查根節點，最壞情況是查到葉子節點)。而B+樹的每一次查找都是穩定的，都要到葉子節點

2.B+樹的優勢

單一節點存儲更多元素，io更少

所有查詢都要查找到葉子節點，查找性能穩定

所有葉子節點形成有序鏈表，便于范圍查詢

3.B+樹應用場合

大部分的關系數據庫，如Mysql

三、為什么B+樹比B樹更適合實際應用中操作系統的文件索引和數據庫索引

因為數據表的索引比較大，不能常駐內存，所以以文件形式存儲在磁盤中。當查詢數據的時候就需要I/O操作。高效率查詢的目標是較少的I/O次數。一次I/O一般是讀取一頁大小的數據。當申請一個節點時，就以頁的大小來申請。也就是說一次I/O可以讀取一個節點的數據。這樣，B樹也可以作為索引數據結構，但是最終還是選擇了B+樹。

①B+樹的內部節點并沒有指向關鍵字具體信息。因此可以存儲更多的數據。索引樹更加矮胖，I/O次數更少

②B+樹的查詢效率更加穩定

由于非終節點并不是最終指向文件內容的節點，而只是葉子節點中關鍵字的索引。所以任何關鍵字的查找必須從根節點到葉子節點。所有關鍵字查詢路徑長度相同，導致每一個數據的查詢效率相當。

③范圍查找簡單：B+樹不需要中序遍歷，遍歷鏈表即可。

四、hash比B+樹更快，為啥mysql還用B+樹來存索引

和具體的業務場景有關，如果只選一個數據，那確實hash更快。但是數據庫中經常會選擇多條，這時B+樹索引就更快了。

而且數據庫中索引一般放在磁盤中，數據量大的情況，無法一次裝入內存，B+數的設計可以允許數據分批加載，同時樹的高度較低，提高查找效率。

總結

以上是生活随笔為你收集整理的mysql 节点查根_（三）B数、B+树及在数据库索引中应用的全部內容，希望文章能夠幫你解決所遇到的問題。

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