MySQL索引原理

在互聯(lián)網(wǎng)行業(yè)减江,常用的關(guān)系型數(shù)據(jù)庫是MySQL泽本,所以在招聘過程中淘太,面試官一般都會問些關(guān)于MySQL的問題,比如MySQL的優(yōu)化观挎、MySQL的事物特性琴儿、隔離級別段化,以及MySQL索引相關(guān)的原理嘁捷。下面我們就來聊一下MySQL索引相關(guān)的內(nèi)容。

一显熏、索引的數(shù)據(jù)結(jié)構(gòu)

我們在線上遇到慢查詢的情況雄嚣,一般第一個想到的優(yōu)化方式就是給where語句后的字段加索引,雖然效果是立竿見影的喘蟆,但這通常是懶人做法缓升。一方面是因為索引并不是都會生效,可能出現(xiàn)加了索引蕴轨,查詢依舊慢的問題港谊,另一方面,索引會占用磁盤空間橙弱。

但是歧寺,這并不妨礙我們在遇到慢查詢的時候,第一個想到的解決方案就是加索引棘脐,那么斜筐,為什么加了索引之后,就能優(yōu)化慢查詢蛀缝,提升查詢速度顷链?

其實,索引就是一種優(yōu)化查詢的數(shù)據(jù)結(jié)構(gòu)屈梁,MySQL中的索引就是用B+樹實現(xiàn)的嗤练。那么為什么MySQL會選擇B+樹作為索引的實現(xiàn)數(shù)據(jù)結(jié)構(gòu)呢榛了?它和哈希表、完全平衡二叉樹煞抬、B樹有什么不同忽冻?

假設(shè),我們現(xiàn)在有下面的user表:

user

① 哈希表

我們知道此疹,hashMap(1.7)底層就是通過哈希表來實現(xiàn)的僧诚,即,數(shù)組+鏈表的方式蝗碎。
哈希表的缺點有兩個: 一湖笨、hash沖突,二蹦骑、只支持精確查詢慈省,不支持范圍查詢,如果我們要某個年齡大于18的用戶眠菇,如下:

select * from user where name = '關(guān)羽'; // 精確查找
select * from user where name > '關(guān)羽'; // 范圍查找

這種情況哈希表并不能實現(xiàn)边败,所以,哈希表不適合做MySQL的索引數(shù)據(jù)結(jié)構(gòu)捎废。

②完全平衡二叉樹

平衡二叉樹的每個節(jié)點都包含下面四部分信息:

  1. 左指針笑窜,指向左子樹
  2. 鍵值
  3. 鍵值所對應(yīng)的數(shù)據(jù)存儲地址
  4. 右指針,指向右子樹

另外登疗,二叉樹是有序的排截,簡而言之,就是左節(jié)點小于右節(jié)點辐益,所以断傲,平衡二叉樹是支持范圍查找的,但是智政,在精確查找的時候认罩,會涉及到多次,比如续捂,查劉備垦垂,需要查詢?nèi)尾拍苷业剑裙1淼木_查找要慢疾忍。

③ B樹

可以看到乔外,B樹在層級上比平衡二叉樹要少一層,即少一次磁盤IO一罩,原因在于杨幼,B樹中的一個節(jié)點可以存儲多個元素。

④ B+樹

B+樹的葉子節(jié)點和B樹是一樣的,只不過冗余了一分非葉子節(jié)點的數(shù)據(jù)

B+樹比B樹要胖一些差购,原因在于B+樹中的非葉子節(jié)點會冗余一分在葉子節(jié)點中四瘫,并且葉子節(jié)點之間用指針相連。

綜上欲逃,我們可以看出找蜜,有三種數(shù)據(jù)結(jié)構(gòu)是適合做MySQL索引的數(shù)據(jù)結(jié)構(gòu)的,平衡二叉樹稳析、B樹洗做、B+樹。這三種數(shù)據(jù)結(jié)構(gòu)都支持精確查找和范圍查找彰居,那么為什么MySQL卻選中了B+樹作為索引的數(shù)據(jù)結(jié)構(gòu)呢诚纸?

其實,索引也是存儲元素的陈惰,當我們的一個表中的數(shù)據(jù)越來越多時畦徘,對應(yīng)的索引文件也會越來越大,這樣就不能把全部的索引文件放在內(nèi)存抬闯,不得不將索引文件存儲在磁盤上井辆,那么選用哪種數(shù)據(jù)結(jié)構(gòu),能夠提高磁盤的IO效率溶握,就成了參考項杯缺。

如果使用完全平衡二叉樹來查詢“張飛”,則需要四次IO奈虾,而使用B樹的話夺谁,只要三次就可以了廉赔,提升了磁盤IO效率肉微,而B+樹和B樹的非葉子節(jié)點是一樣的,只不過是葉子節(jié)點冗余了一份非葉子節(jié)點的數(shù)據(jù)蜡塌。所以碉纳,在精確查找上,B樹和B+樹是一樣的馏艾,而B+樹在范圍查找上優(yōu)于B樹劳曹。

二、 B+樹的節(jié)點到底多大合適

B+樹的一個節(jié)點為一頁或者一頁的整數(shù)倍最為合適琅摩,因為讀取這個節(jié)點的時候铁孵,是按照一頁來讀取的,大于或小于一頁房资,會造成資源浪費蜕劝。
在MySQL的Innodb引擎中,一頁的默認大小是16K(如果操作系統(tǒng)的一頁大小是4K,那么Mysql中一頁=操作系統(tǒng)中4頁)岖沛,可以使用如下命令查看:

show global status like 'Innodbpagesize';
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末暑始,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子婴削,更是在濱河造成了極大的恐慌廊镜,老刑警劉巖,帶你破解...
    沈念sama閱讀 206,311評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件唉俗,死亡現(xiàn)場離奇詭異嗤朴,居然都是意外死亡,警方通過查閱死者的電腦和手機虫溜,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,339評論 2 382
  • 文/潘曉璐 我一進店門播赁,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人吼渡,你說我怎么就攤上這事容为。” “怎么了寺酪?”我有些...
    開封第一講書人閱讀 152,671評論 0 342
  • 文/不壞的土叔 我叫張陵坎背,是天一觀的道長。 經(jīng)常有香客問我寄雀,道長得滤,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 55,252評論 1 279
  • 正文 為了忘掉前任盒犹,我火速辦了婚禮懂更,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘急膀。我一直安慰自己沮协,他們只是感情好,可當我...
    茶點故事閱讀 64,253評論 5 371
  • 文/花漫 我一把揭開白布卓嫂。 她就那樣靜靜地躺著慷暂,像睡著了一般。 火紅的嫁衣襯著肌膚如雪晨雳。 梳的紋絲不亂的頭發(fā)上行瑞,一...
    開封第一講書人閱讀 49,031評論 1 285
  • 那天,我揣著相機與錄音餐禁,去河邊找鬼血久。 笑死,一個胖子當著我的面吹牛帮非,可吹牛的內(nèi)容都是我干的氧吐。 我是一名探鬼主播绷旗,決...
    沈念sama閱讀 38,340評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼副砍!你這毒婦竟也來了衔肢?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 36,973評論 0 259
  • 序言:老撾萬榮一對情侶失蹤豁翎,失蹤者是張志新(化名)和其女友劉穎角骤,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體心剥,經(jīng)...
    沈念sama閱讀 43,466評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡邦尊,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,937評論 2 323
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了优烧。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片蝉揍。...
    茶點故事閱讀 38,039評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖畦娄,靈堂內(nèi)的尸體忽然破棺而出又沾,到底是詐尸還是另有隱情,我是刑警寧澤熙卡,帶...
    沈念sama閱讀 33,701評論 4 323
  • 正文 年R本政府宣布杖刷,位于F島的核電站,受9級特大地震影響驳癌,放射性物質(zhì)發(fā)生泄漏滑燃。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,254評論 3 307
  • 文/蒙蒙 一颓鲜、第九天 我趴在偏房一處隱蔽的房頂上張望表窘。 院中可真熱鬧,春花似錦甜滨、人聲如沸乐严。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,259評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽麦备。三九已至,卻和暖如春昭娩,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背黍匾。 一陣腳步聲響...
    開封第一講書人閱讀 31,485評論 1 262
  • 我被黑心中介騙來泰國打工栏渺, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人锐涯。 一個月前我還...
    沈念sama閱讀 45,497評論 2 354
  • 正文 我出身青樓磕诊,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子霎终,可洞房花燭夜當晚...
    茶點故事閱讀 42,786評論 2 345

推薦閱讀更多精彩內(nèi)容