B+樹在磁盤存儲中的應用

歡迎探討，若有錯誤敬請指正

如需轉載，請註明出處 http://www.cnblogs.com/nullzx/

---

咱們首先提一個問題， B+樹比平衡二叉樹在索引數據方面要快麼？

大多數人可能認爲確定仍是B+樹快，畢竟存儲一樣多的數據，100階的B+樹確定比平衡二叉樹的高度要低的多。可是別忘了B樹在一個結點可能須要比較不少次才能找到下一層的結點，可是平衡二叉樹只要比較一次就能夠向下走一層。因此綜合起來，其實二者索引的速度幾乎（甚至說就是）是同樣的。最簡單的道理，一顆4階B樹就是一顆紅黑樹，比較的次數徹底同樣（若是不明白這個道理，請參考我關於紅黑樹的三篇技術博客）。那麼咱們爲何還要使用B+樹呢？這是由於上面說索引速度至關的前提是二者的數據結構都位於內存中，當咱們要在磁盤上索引一個記錄時，將磁盤中的數據傳輸到內存中才是花費時間的大頭，而在內存中的索引過程所花的時間基本是能夠忽略不計的。在磁盤中以B+樹的形式組織數據就有着自然的優點。要解釋這個道理，咱們必須先強調一個概念，主存和磁盤之間的數據交換不是以字節爲單位的，而是以n個扇區爲單位的（一個扇區有512字節），一般是4KB（8個扇區），8KB（16個扇區），16KB，……64KB爲單位的。假設，咱們如今選擇4KB做爲內存和磁盤之間的傳輸單位，那麼咱們在設計B+樹的時候，不管是索引結點仍是葉子結點都使用4KB做爲結點的大小。咱們這時不妨再假設一個記錄的大小是1KB，那麼一個葉子結點能夠存4個記錄。而對於索引結點（大小也是4KB），因爲只須要存key值和相應的指針，因此一個索引結點可能能夠存儲100~150個分支，咱們不妨就取100吧。固然這和B樹和B+樹的插入、刪除圖文詳解第2節和第3節中的狀況不太同樣，由於如今索引結點的階數是100，而葉子結點的階數是4，二者並不一致，但這並無什麼問題。

咱們考慮如上圖所示的B+樹，下面的B+樹有三層，兩層是索引結點，最後一層是葉子結點。那麼這個三層的B+樹最多能夠存400萬個記錄。若是這個B+樹存儲到硬盤中，咱們怎麼根據記錄的key找到對應的記錄呢？首先咱們要讀取這個B+樹的根結點到內存（花費一個IO的時間）而後在內存中進行索引，根據key找到對應的分支，再將這個分支所指向的第二層索引結點讀取到內存中（花費第二個IO時間）而後在內存中進行索引，一樣根據key找到對應的分支，而這個分支指向的就是葉子結點，咱們最後將這個葉子結點讀取到內存中（花費的第三個IO時間）判斷是否存在這個記錄。這樣咱們只須要經過三次IO時間就從400萬個記錄中找到了對應的key記錄，能夠說是很是快了。快速的緣由是，索引結點中不存數據，只存鍵和指針，因此一個索引結點就能夠存儲大量的分支，而一個索引結點只須要一次IO便可讀取到內存中。

咱們如今再考慮一個問題，當記錄的大小可變時，葉子結點中記錄該如何存儲？

這個時候有兩種極限狀況。

1）假設葉子結點的階數仍然爲4，但每一個記錄僅僅有100個字節，顯然當葉子結點中存滿4個記錄後，葉子結點中仍然有大量的剩餘空間。這個時候咱們能不能直接向該葉子結點中插入數據，而沒必要分裂這個葉子結點（分裂指在磁盤中的分裂）？答案是能夠，有人必定會說，這不就違反B+樹的定義了麼？的確違反了，可是B+樹之因此定義階數的目的是爲了平衡（或者說加強）每個分支的索引效率，不過這個優勢僅當整個B+樹都位於內存時才能體現出來。當B+樹存儲在磁盤中的狀況時，IO效率纔是第一要考慮的因素。CPU在某個結點內部多比較幾回或少比較幾回和IO花費的時間相比就不值得一提了。而不分裂反而能提高B+樹的IO效率，由於分裂須要更多的IO次數。綜合起來了說就是，文件系統及數據庫中的B+樹是不考慮階數這一個概念的，結點（即包括葉子結點，也包括索引結點）中僅遵行一個規則，若是剩餘空間夠大那麼就存入數據，若是剩餘空間不夠，只能分裂後再存入。

2）若是某條記錄太大，即便葉子結點中還剩餘一多半的空間但仍然存不下怎麼辦？這個時候MySql稱之爲行溢出，簡單的解決方式就是把記錄存儲在溢出頁（磁盤的其它空閒地方）中，而後葉子結點中存儲的是這個記錄的指針。

補充：若是按照key值的大小順序插入，按照B+樹定義的方式進行分裂時，每一個葉子結點的存儲效率只有50%，爲了解決這個問題，咱們能夠採起這樣的分裂方式：原葉子結點中的數據不動，建立一個新的空葉子結點，記錄插入到新葉子節點中。這樣磁盤的插入效率就很高，並且每一個葉子結點的利用率也很高。但這種分裂方式僅僅對按key的大小將記錄順序插入纔有效，隨機插入條件反而不如50%分裂的方式。

 

參考內容

[1] B+樹介紹

[2] 從MySQL Bug#67718淺談B+樹索引的分裂優化

[3] B+樹的幾點總結