關(guān)于MySQL?B+樹索引與哈希索引詳解
索引介紹
索引是一種特殊的數(shù)據(jù)庫結(jié)構(gòu),被設(shè)計用來快速查詢數(shù)據(jù)庫表中的特定記錄。索引有多種類型,就像字典有拼音查找和偏旁查找一樣都是為了提高檢索效率。MySQL中最常見的索引類型有
B+樹索引
和哈希索引
,下面來簡單介紹一下這兩種索引類型有哪些差別和優(yōu)劣。
B+樹索引
B+樹索引是一種多路徑的平衡搜索樹,具有如下特點(diǎn):
1.非葉子節(jié)點(diǎn)不保存數(shù)據(jù),只保存索引值
2.葉子節(jié)點(diǎn)保存所有的索引值和數(shù)據(jù)
3.同級節(jié)點(diǎn)通過指針自小而大順序鏈接
4.節(jié)點(diǎn)內(nèi)的數(shù)據(jù)也是自小而大順序存放
5.葉子節(jié)點(diǎn)擁有父節(jié)點(diǎn)的所有信息
結(jié)構(gòu)如下圖:
優(yōu)點(diǎn)
由于數(shù)據(jù)順序存放,所以無論是區(qū)間還是順序掃描都更快。
非葉子節(jié)點(diǎn)不存儲數(shù)據(jù),因此幾乎都能放在內(nèi)存中,搜索效率更高
單節(jié)點(diǎn)中可存儲的數(shù)據(jù)更多,平均掃描I/O請求樹更少
平均查詢效率穩(wěn)定(每次查詢都從根結(jié)點(diǎn)到葉子結(jié)點(diǎn),查詢路徑長度相同)
缺點(diǎn)
新增數(shù)據(jù)不是按順序遞增時,索引樹需要重新排列,容易造成碎片和頁分裂情況。
哈希索引
哈希索引采用一定的哈希算法,把鍵值換算成新的哈希值,檢索時不需要類似B+樹那樣從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)逐級查找,只需一次哈希算法即可立刻定位到相應(yīng)的位置,速度非???,具有如下特點(diǎn):
1.哈希索引建立在哈希表的基礎(chǔ)上
2.對于每個值,需要先計算出對應(yīng)的哈希碼(Hash Code),不同值的哈希碼唯一
3.把哈希碼保存在哈希表中,同時哈希表也保存指向?qū)?yīng)每行記錄的指針
結(jié)構(gòu)如下圖:
優(yōu)點(diǎn)
大量唯一等值查詢時,哈希索引效率通常更高。
缺點(diǎn)
哈希索引對于范圍查詢和模糊匹配查詢顯得無能為力。
哈希索引不支持排序操作,對于多列聯(lián)合索引的最左匹配規(guī)則也不支持。
哈希索引不支持前綴索引,因為哈希索引始終是使用索引列的全部內(nèi)容來計算哈希值。
如果存在哈希沖突的情況,也就是不同的索引列有著相同的哈希值,這時候需要遍歷鏈表中所有的行指針進(jìn)行逐行比對,直到找到所有滿足條件的行,效率較低。
補(bǔ)充:二者區(qū)別
備注:先說下,在MySQL文檔里,實際上是把B+樹索引寫成了BTREE,例如像下面這樣的寫法:
CREATE TABLE t( aid int unsigned not null auto_increment, userid int unsigned not null default 0, username varchar(20) not null default ‘', detail varchar(255) not null default ‘', primary key(aid), unique key(uid) USING?BTREE, key (username(12)) USING?BTREE?—?此處 uname 列只創(chuàng)建了最左12個字符長度的部分索引 )engine=InnoDB;
B+樹是一個平衡的多叉樹,從根節(jié)點(diǎn)到每個葉子節(jié)點(diǎn)的高度差值不超過1,而且同層級的節(jié)點(diǎn)間有指針相互鏈接。
在B+樹上的常規(guī)檢索,從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的搜索效率基本相當(dāng),不會出現(xiàn)大幅波動,而且基于索引的順序掃描時,也可以利用雙向指針快速左右移動,效率非常高。
因此,B+樹索引被廣泛應(yīng)用于數(shù)據(jù)庫、文件系統(tǒng)等場景。順便說一下,xfs文件系統(tǒng)比ext3/ext4效率高很多的原因之一就是,它的文件及目錄索引結(jié)構(gòu)全部采用B+樹索引,而ext3/ext4的文件目錄結(jié)構(gòu)則采用Linked list, hashed B-tree、Extents/Bitmap等索引數(shù)據(jù)結(jié)構(gòu),因此在高I/O壓力下,其IOPS能力不如xfs。
簡單地說,哈希索引就是采用一定的哈希算法,把鍵值換算成新的哈希值,檢索時不需要類似B+樹那樣從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)逐級查找,只需一次哈希算法即可立刻定位到相應(yīng)的位置,速度非???。
從上面的圖來看,B+樹索引和哈希索引的明顯區(qū)別是:
如果是等值查詢,那么哈希索引明顯有絕對優(yōu)勢,因為只需要經(jīng)過一次算法即可找到相應(yīng)的鍵值;當(dāng)然了,這個前提是,鍵值都是唯一的。如果鍵值不是唯一的,就需要先找到該鍵所在位置,然后再根據(jù)鏈表往后掃描,直到找到相應(yīng)的數(shù)據(jù);
從示意圖中也能看到,如果是范圍查詢檢索,這時候哈希索引就毫無用武之地了,因為原先是有序的鍵值,經(jīng)過哈希算法后,有可能變成不連續(xù)的了,就沒辦法再利用索引完成范圍查詢檢索;
同理,哈希索引也沒辦法利用索引完成排序,以及l(fā)ike ‘xxx%’ 這樣的部分模糊查詢(這種部分模糊查詢,其實本質(zhì)上也是范圍查詢);
哈希索引也不支持多列聯(lián)合索引的最左匹配規(guī)則;
B+樹索引的關(guān)鍵字檢索效率比較平均,不像B樹那樣波動幅度大,在有大量重復(fù)鍵值情況下,哈希索引的效率也是極低的,因為存在所謂的哈希碰撞問題。
總結(jié)
到此這篇關(guān)于MySQL B+樹索引與哈希索引的文章就介紹到這了,更多相關(guān)MySQL B+樹索引與哈希索引內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
mysql截取json對象特定數(shù)據(jù)的場景示例詳解
這篇文章主要為大家介紹了mysql中截取json對象特定數(shù)據(jù)的場景示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-07-07MySQL存儲引擎InnoDB與Myisam的區(qū)別分析
INNODB會支持一些關(guān)系數(shù)據(jù)庫的高級功能,如事務(wù)功能和行級鎖,MYISAM不支持。MYISAM的性能更優(yōu),占用的存儲空間少。所以,選擇何種存儲引擎,視具體應(yīng)用而定。2022-12-12