MySQL中B樹索引和B+樹索引的區別詳解

2022-03-02 19:02:31

如果用樹作為索引的資料結構，每查詢一次資料就會從磁碟中讀取樹的一個節點，也就是一頁，而二元樹的每個節點只儲存一條資料，並不能填滿一頁的儲存空間，那多餘的儲存空間豈不是要浪費了？為了解決二叉平衡搜尋樹的這個弊端，我們應該尋找一種單個節點可以儲存更多資料的資料結構，也就是多路搜尋樹。

1. 多路搜尋樹

1、完全二元樹高度：O(log2N)，其中2為對數，樹每層的節點數；

2、完全M路搜尋樹的高度：O(logmN)，其中M為對數，樹每層的節點數；

3、M路搜尋樹主要用於解決資料量大無法全部載入到記憶體的資料儲存。通過增加每層節點的個數和在每個節點存放更多的資料來在一層中存放更多的資料，從而降低樹的高度，在資料查詢時減少磁碟存取次數。

4、所以每層的節點數和每個節點包含的關鍵字越多，則樹的高度越矮。但是在每個節點確定資料就越慢，但是B樹關注的是磁碟效能瓶頸，所以在單個節點搜尋資料的開銷可以忽略。

2. B樹-多路平衡搜尋樹

B樹是一種M路搜尋樹，B樹主要用於解決M路搜尋樹的不平衡導致樹的高度變高，跟二元樹退化為連結串列導致效能問題一樣。B樹通過對每層的節點進行控制、調整，如節點分離，節點合併，一層滿時向上分裂父節點來增加新的層等操作來來保證該M路搜尋樹的平衡。

M為B樹的階數或者說是路數，在B樹中，每個節點都是一個磁碟塊(頁)。每個非葉子節點存放了關鍵字和指向兒子樹的指標，具體數量為：M階的B樹，每個非葉子節點存放了M-1個關鍵字和M個指向子樹的指標。如圖為5階B樹結構的示意圖：

3. B樹索引

首先建立一張user表：

create table user(
	id int,
	name varchar,
	primary key(id)
) ROW_FORMAT=COMPACT;

假如我們使用B樹對錶中的使用者記錄建立索引：

B樹的每個節點佔用一個磁碟塊，磁碟塊也就是頁，從上圖可以看出，B樹相對於平衡二元樹，每個節點儲存了更多的主鍵key和資料data，並且每個節點擁有了更多的子節點，子節點的個數一般稱為階，上述圖中的B樹為3階B樹，高度也會降低。假如我們要查詢id=28的使用者資訊，那麼查詢流程如下：

1、根據根節點找到頁1，讀入記憶體。【磁碟I/O操作第1次】

2、比較鍵值28在區間（17,35），找到頁1的指標p2；

3、根據p2指標找到頁3，讀入記憶體。【磁碟I/O操作第2次】

4、比較鍵值28在區間（26,35），找到頁3的指標p2。

5、根據p2指標找到頁8，讀入記憶體。【磁碟I/O操作第3次】

6、在頁8中的鍵值列表中找到鍵值28，鍵值對應的使用者資訊為(28,po)；

B-Tree相對於AVLTree縮減了節點個數，使每次磁碟I/O取到記憶體的資料都發揮了作用，從而提高了查詢效率。

4. B+樹索引

B+Tree是在B-Tree基礎上的一種優化，使其更適合實現外儲存索引結構，B+樹的性質：

1、非葉子節點的子樹指標與關鍵字個數相同；

2、為所有葉子節點增加一個鏈指標；

3、所有關鍵字都在葉子節點出現，且連結串列中的關鍵字恰好是有序的；

4、非葉子節點相當於是葉子節點的索引,葉子節點相當於是儲存(關鍵字)資料的資料層；

InnoDB儲存引擎就是用B+Tree實現其索引結構。

從上一節中的B-Tree結構圖中可以看到每個節點中不僅包含資料的key值，還有data值。而每一個頁的儲存空間是有限的，如果data資料較大時將會導致每個節點（即一個頁）能儲存的key的數量很小，當儲存的資料量很大時同樣會導致B-Tree的深度較大，增大查詢時的磁碟I/O次數，進而影響查詢效率。在B+Tree中，所有資料記錄節點都是按照鍵值大小順序存放在同一層的葉子節點上，而非葉子節點上只儲存key值資訊，這樣可以大大加大每個節點儲存的key值數量，降低B+Tree的高度。

B+Tree相對於B-Tree有幾點不同：

1、非葉子節點只儲存鍵值資訊和指向子節點頁號的指標；

2、所有葉子節點之間都有一個鏈指標；

3、資料記錄都存放在葉子節點中；