B+樹特點

考慮因素

支持按照區間來查找數據
磁盤 IO 操作
N叉樹

樹的高度就等于每次查詢數據時磁盤 IO 操作的次數
在選擇 m 大小的時候，要盡量讓每個節點的大小等于一個頁的大小。讀取一個節點，只需要一次磁盤 IO 操作。（分裂成兩個節點）

問題

跳表和B+樹在實現難度和性能上有什么區別，在數據量很大的情況下，表現性能如何，為什么redis選跳表？
b+樹主要是用在外部存儲上，為了減少磁盤IO次數。
跳表比較適合內存存儲。
實際上，兩者本質的設計思想是雷同的，性能差距還是要具體看應用場景，無法從時間復雜度這么寬泛的度量標準來度量了。

B+ 樹中，將葉子節點串起來的鏈表，是單鏈表還是雙向鏈表？為什么？

對于B+tree葉子節點，是用雙向鏈表還是用單鏈表，得從具體的場景思考。我想，大部分同學在開發中遇到的數據庫查詢，都遇到過升序或降序問題，即類似這樣的sql: select name,age, … from where uid > startValue and uid < endValue order by uid asc(或者desc)，此時，數據底層實現有兩種做法：
1）保證查出來的數據就是用戶想要的順序
2）不保證查出來的數據的有序性，查出來之后再排序
以上兩種方案，不加思考，肯定選第一種，因為第二種做法浪費了時間（如果選用內存排序，還是考慮數據的量級）。那如何能保證查詢出來的數據就是有序的呢？單鏈表肯定做不到，只能從頭往后遍歷，再想想，只能選擇雙向鏈表了。此時，可能有的同學又問了：雙向鏈表，多出來了一倍的指針，不是會多占用空間嘛？ 答案是肯定的。可是，我們再細想下，數據庫索引本身都已經在磁盤中了，對于磁盤來說，這點空間已經微不足道了，用這點空間換來時間肯定劃算呀。順便提一下：在實際工程應用中，雙向鏈表應用的場景非常廣泛，畢竟能大量減少鏈表的遍歷時間

如果我們把散列表中的結點，也用鏈表串起來，能否支持按照區間查找數據呢？

答案是「肯定的」。JDK中的LinkedHashMap為了能做到保持節點的順序（插入順序或者訪問順序），就是用雙向鏈表將節點串起來的。

筆記整理來源： 王爭 數據結構與算法之美

總結

以上是生活随笔為你收集整理的【数据结构与算法】【算法思想】【MySQL数据库索引】B+树的全部內容，希望文章能夠幫你解決所遇到的問題。

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