為什么MySQL數(shù)據(jù)庫要用B+樹存儲(chǔ)索引?
小史是一個(gè)應(yīng)屆生,雖然學(xué)的是電子專業(yè),但是自己業(yè)余時(shí)間看了很多互聯(lián)網(wǎng)與編程方面的書,一心想進(jìn) BAT 互聯(lián)網(wǎng)公司。
話說兩個(gè)多月前,小史通過了 A 廠的一面,兩個(gè)多月后的今天,小史終于等到了 A 廠的二面。
在簡單的自我介紹后,面試官看了看小史的簡歷,開始發(fā)問了。
面試現(xiàn)場
小史:沒問題,這個(gè)項(xiàng)目前端用的 React+Webpack,后端用的 Nginx+Spring Boot+Redis+MySQL,前后端是分離的,***用 Docker 進(jìn)行容器化部署。主要模塊有師生系統(tǒng)、課程系統(tǒng)、成績系統(tǒng)、選課系統(tǒng)等。
這個(gè)項(xiàng)目的架構(gòu)和說辭,小史早已背得溜溜的。
小史:底層 MySQL 是存儲(chǔ),Redis 是緩存,Dao 層操作 MySQL,Cache層操作 Redis,Service 層處理業(yè)務(wù)邏輯,Rest API 層為前端提供 Rest 接口。
前端這邊用 React 進(jìn)行模塊化,Webpack 打包部署。網(wǎng)關(guān) Nginx 進(jìn)行負(fù)載均衡。MySQL、Redis、Nginx 和 Spring Boot 應(yīng)用都放在 Docker 里部署。
題目:為什么 MySQL 數(shù)據(jù)庫要用 B+ 樹存儲(chǔ)索引?小史聽到這個(gè)題目,陷入了回憶。
前段時(shí)間的飯局
話說呂老師給小史講完人工智能的一些知識(shí)后,他們一起回家吃小史姐姐做的飯去了。
呂老師:面試的時(shí)候一定是往深了問,不精通的話容易吃虧。不過面試時(shí)一般都是根據(jù)項(xiàng)目來問,項(xiàng)目中用到的技術(shù),一定要多看看原理,特別是能和數(shù)據(jù)結(jié)構(gòu)和算法掛鉤的那部分。
小史:樹的話,無非就是前中后序遍歷、二叉樹、二叉搜索樹、平衡二叉樹,更高級(jí)一點(diǎn)的有紅黑樹、B 樹、B+ 樹,還有之前你教我的字典樹。
紅黑樹
一聽到紅黑樹,小史頭都大了,開始抱怨了起來。
小史:紅黑樹看過很多遍了,但是每次都記不住,它的規(guī)則實(shí)在是太多了,光定義就有四五條規(guī)則,還有插入刪除的時(shí)候,需要調(diào)整樹,復(fù)雜得很。
呂老師:小史,問你紅黑樹,并不是讓你背誦它的定義,或者讓你手寫一個(gè)紅黑樹,而是想問問你它為什么這樣設(shè)計(jì),它的使用場景有哪些。
B 樹
呂老師:小史,你要知道,文件系統(tǒng)和數(shù)據(jù)庫的索引都是存在硬盤上的,并且如果數(shù)據(jù)量大的話,不一定能一次性加載到內(nèi)存中。
兩個(gè)月前,小史面試沒考慮內(nèi)存情況差點(diǎn)掛了。
B+ 樹
呂老師:這也是和業(yè)務(wù)場景相關(guān)的,你想想,數(shù)據(jù)庫中 Select 數(shù)據(jù),不一定只選一條,很多時(shí)候會(huì)選多條,比如按照 ID 排序后選 10 條。
小史:我明白了,如果是多條的話,B 樹需要做局部的中序遍歷,可能要跨層訪問。
而 B+ 樹由于所有數(shù)據(jù)都在葉子結(jié)點(diǎn),不用跨層,同時(shí)由于有鏈表結(jié)構(gòu),只需要找到首尾,通過鏈表就能把所有數(shù)據(jù)取出來了。
回到現(xiàn)場
小史:這和業(yè)務(wù)場景有關(guān)。如果只選一個(gè)數(shù)據(jù),那確實(shí)是 Hash 更快。但是數(shù)據(jù)庫中經(jīng)常會(huì)選擇多條,這時(shí)候由于 B+ 樹索引有序,并且又有鏈表相連,它的查詢效率比 Hash 就快很多了。
小史:而且數(shù)據(jù)庫中的索引一般是在磁盤上,數(shù)據(jù)量大的情況可能無法一次裝入內(nèi)存,B+ 樹的設(shè)計(jì)可以允許數(shù)據(jù)分批加載,同時(shí)樹的高度較低,提高查找效率。
HR 和小史簡單地聊了聊基本情況,這次面試就結(jié)束了。小史走后,面試官在系統(tǒng)中寫下了面試評(píng)語:
幾天后,小史收到了 A 廠的 Offer。