mysql使用B Tree作為索引資料結構的原因

2021-10-10 09:30:30 字數 1032 閱讀 1611

mysql使用的是b+-tree,時間複雜度是o(log n)

hash索引的複雜度是o(1),如果是查詢乙個數的話,使用hash是很好的選擇,但是對於範圍查詢,模糊查詢都不支援,並且由於hash函式的隨機性,通常其對記憶體的訪問也是隨機的,會造成頻繁的io,然而在資料庫效能調優方面,有乙個點就是要減少不必要的io,然而mysql並沒有放棄這種快速搜尋等值的查詢方式,而是根據資料庫訪問頻率和模式自動的為資料建立雜湊索引,稱之為自適應雜湊索引。

再說說二叉樹,如果左子樹不為空,則左子樹上所有節點均小於根節點,右子樹節點均大於根節點,這種資料結構非常適合資料的查詢,但是有個致命的確定就是二叉搜尋樹的樹形取決於資料的輸入順序,在極端的情況會退化成煉表。造成了二叉搜尋樹搜尋效率的不穩定型。

此時平衡二叉樹的出現解決了二叉樹存在的問題,它是一種能夠自動調整樹形(保證資料順序的基礎上,又能維持樹型),並且保證每個節點的左右子樹高度不超過1。但是這種樹在插入資料時進行調整可能需要進行大量的資料移動,恰恰由於平衡二叉樹過於嚴格的平衡要求,使得每一次的插入和刪除都需要耗費大量的資源去進行調整樹型結構,從而使它的效能大打折扣。

而紅黑樹能夠有效減少節點的移動次數,它不像平衡二叉樹一樣嚴苛,但是又維持了平衡二叉樹能夠快速查詢資料的優勢,但由於紅黑樹的深度過大,資料檢索的時候會造成磁碟io頻繁,因此,mysql也並未將其作為索引實現。

b-tree是一種自平衡的多叉查詢樹,乙個節點可以擁有兩個以上的子節點,其索引與資料儲存在一塊。由於mysql索引一般都存在在記憶體中,而記憶體資源往往比較寶貴,一定記憶體的情況下可以儲存的索參數量相對有限,就導致了不適合使用索引與資料儲存在一起的資料結構,並且b-tree對於順序查詢並不友好。

b+-tree是b-tree的加強版,主要不同點是b+-tree的資料只存在葉子節點中,並且葉子節點之間通過指標相連,為雙向鍊錶結構,這種資料結構解決了記憶體資源寶貴只能儲存索引的問題,也解決了順序查詢中頻繁io的問題。

總結:b+-tree的優點:

1.樹高很低,在儲存大資料情況下,依然能保持較少的磁碟io

2.支援範圍查詢,有序性查詢

3.索引和資料分開儲存,讓更多的索引儲存在記憶體中

mysql索引hash索引和b tree索引的區別

mysql下增加索引的方式 修改表結構 alter mytable add index indexname on username length 建立表結構 create table mytable id int not null,username varchar 16 not null,index...

Mysql優化 B Tree索引和Hash索引

b tree和普通的b tree不大一樣。有個 可以體驗這些資料結構 先看一下b tree 設定最大深度為3,插入10個數字,資料結構如上,他與普通的二叉樹區別在於每個節點有多個資料,相當於橫向擴充套件,減少深度。為什麼要減少深度 當資料量比較大的時候,mysql無法將索引全部載入到記憶體中,只能逐...

Oracle的b tree和bitmap索引

number型別建立乙個bitmap索引 select from test where flag 1 執行結果 table access full 12573 分析 出現全表掃瞄而沒有執行位圖索引,可能是flag為1的資料量和表的資料量相當,所以優化器將其優化掉了.varchar2型別欄位上建立乙個...