爲何Mysql用B+樹作索引而不用B-樹

先從數據結構的角度來答。sql

 

題主應該知道B-樹和B+樹最重要的一個區別就是B+樹只有葉節點存放數據,其他節點用來索引,而B-樹是每一個索引節點都會有Data域。
這就決定了B+樹更適合用來存儲外部數據,也就是所謂的磁盤數據。
從Mysql(Inoodb)的角度來看,B+樹是用來充當索引的,通常來講索引很是大,尤爲是關係性數據庫這種數據量大的索引能達到億級別,因此爲了減小內存的佔用,索引也會被存儲在磁盤上。
那麼Mysql如何衡量查詢效率呢?磁盤IO次數,B-樹(B類樹)的特定就是每層節點數目很是多,層數不多,目的就是爲了就少磁盤IO次數,當查詢數據的時候,最好的狀況就是很快找到目標索引,而後讀取數據,使用B+樹就能很好的完成這個目的,可是B-樹的每一個節點都有data域(指針),這無疑增大了節點大小,說白了增長了磁盤IO次數(磁盤IO一次讀出的數據量大小是固定的,單個數據變大,每次讀出的就少,IO次數增多,一次IO多耗時啊!),而B+樹除了葉子節點其它節點並不存儲數據,節點小,磁盤IO次數就少。這是優勢之一。
另外一個優勢是什麼,B+樹全部的Data域在葉子節點,通常來講都會進行一個優化,就是將全部的葉子節點用指針串起來。這樣遍歷葉子節點就能得到所有數據,這樣就能進行區間訪問啦。數據庫

(數據庫索引採用B+樹的主要緣由是 B樹在提升了磁盤IO性能的同時並無解決元素遍歷的效率低下的問題。正是爲了解決這個問題,B+樹應運而生。B+樹只要遍歷葉子節點就能夠實現整棵樹的遍歷。並且在數據庫中基於範圍的查詢是很是頻繁的,而B樹不支持這樣的操做(或者說效率過低))數據結構

至於MongoDB爲何使用B-樹而不是B+樹,能夠從它的設計角度來考慮,它並非傳統的關係性數據庫,而是以Json格式做爲存儲的nosql,目的就是高性能,高可用,易擴展。首先它擺脫了關係模型,上面所述的優勢2需求就沒那麼強烈了,其次Mysql因爲使用B+樹,數據都在葉節點上,每次查詢都須要訪問到葉節點,而MongoDB使用B-樹,全部節點都有Data域,只要找到指定索引就能夠進行訪問,無疑單次查詢平均快於Mysql(但側面來看Mysql至少平均查詢耗時差很少)。nosql

整體來講,Mysql選用B+樹和MongoDB選用B-樹仍是以本身的需求來選擇的。性能

 

 

B樹相對於紅黑樹的區別優化

在大規模數據存儲的時候,紅黑樹每每出現因爲樹的深度過大而形成磁盤IO讀寫過於頻繁,進而致使效率低下的狀況。爲何會出現這樣的狀況,咱們知道要獲取磁盤上數據,必須先經過磁盤移動臂移動到數據所在的柱面,而後找到指定盤面,接着旋轉盤面找到數據所在的磁道,最後對數據進行讀寫。磁盤IO代價主要花費在查找所需的柱面上,樹的深度過大會形成磁盤IO頻繁讀寫。根據磁盤查找存取的次數每每由樹的高度所決定,因此,只要咱們經過某種較好的樹結構減小樹的結構儘可能減小樹的高度,B樹能夠有多個子女,從幾十到上千,能夠下降樹的高度。.net


--------------------- 
做者:本兮言 
來源:CSDN 
原文:https://blog.csdn.net/ligupeng7929/article/details/79529072 
版權聲明:本文爲博主原創文章,轉載請附上博文連接!設計

相關文章
相關標籤/搜索