小史是一個應屆生，雖然學的是電子專業(yè)，但是自己業(yè)余時間看了很多互聯(lián)網(wǎng)與編程方面的書，一心想進 BAT 互聯(lián)網(wǎng)公司。

話說兩個多月前，小史通過了 A 廠的一面，兩個多月后的今天，小史終于等到了 A 廠的二面。

在簡單的自我介紹后，面試官看了看小史的簡歷，開始發(fā)問了。

面試現(xiàn)場

小史：沒問題，這個項目前端用的 React+Webpack，后端用的 Nginx+Spring Boot+Redis+MySQL，前后端是分離的，***用 Docker 進行容器化部署。主要模塊有師生系統(tǒng)、課程系統(tǒng)、成績系統(tǒng)、選課系統(tǒng)等。

這個項目的架構和說辭，小史早已背得溜溜的。

小史：底層 MySQL 是存儲，Redis 是緩存，Dao 層操作 MySQL，Cache層操作 Redis，Service 層處理業(yè)務邏輯，Rest API 層為前端提供 Rest 接口。

前端這邊用 React 進行模塊化，Webpack 打包部署。網(wǎng)關 Nginx 進行負載均衡。MySQL、Redis、Nginx 和 Spring Boot 應用都放在 Docker 里部署。

題目：為什么 MySQL 數(shù)據(jù)庫要用 B+ 樹存儲索引?小史聽到這個題目，陷入了回憶。

前段時間的飯局

話說呂老師給小史講完人工智能的一些知識后，他們一起回家吃小史姐姐做的飯去了。

呂老師：面試的時候一定是往深了問，不精通的話容易吃虧。不過面試時一般都是根據(jù)項目來問，項目中用到的技術，一定要多看看原理，特別是能和數(shù)據(jù)結構和算法掛鉤的那部分。

 

小史：樹的話，無非就是前中后序遍歷、二叉樹、二叉搜索樹、平衡二叉樹，更高級一點的有紅黑樹、B 樹、B+ 樹，還有之前你教我的字典樹。

紅黑樹

一聽到紅黑樹，小史頭都大了，開始抱怨了起來。

小史：紅黑樹看過很多遍了，但是每次都記不住，它的規(guī)則實在是太多了，光定義就有四五條規(guī)則，還有插入刪除的時候，需要調整樹，復雜得很。

呂老師：小史，問你紅黑樹，并不是讓你背誦它的定義，或者讓你手寫一個紅黑樹，而是想問問你它為什么這樣設計，它的使用場景有哪些。

B 樹

 

呂老師：小史，你要知道，文件系統(tǒng)和數(shù)據(jù)庫的索引都是存在硬盤上的，并且如果數(shù)據(jù)量大的話，不一定能一次性加載到內存中。

兩個月前，小史面試沒考慮內存情況差點掛了。

B+ 樹

 

呂老師：這也是和業(yè)務場景相關的，你想想，數(shù)據(jù)庫中 Select 數(shù)據(jù)，不一定只選一條，很多時候會選多條，比如按照 ID 排序后選 10 條。

小史：我明白了，如果是多條的話，B 樹需要做局部的中序遍歷，可能要跨層訪問。

而 B+ 樹由于所有數(shù)據(jù)都在葉子結點，不用跨層，同時由于有鏈表結構，只需要找到首尾，通過鏈表就能把所有數(shù)據(jù)取出來了。

回到現(xiàn)場

小史：這和業(yè)務場景有關。如果只選一個數(shù)據(jù)，那確實是 Hash 更快。但是數(shù)據(jù)庫中經(jīng)常會選擇多條，這時候由于 B+ 樹索引有序，并且又有鏈表相連，它的查詢效率比 Hash 就快很多了。

小史：而且數(shù)據(jù)庫中的索引一般是在磁盤上，數(shù)據(jù)量大的情況可能無法一次裝入內存，B+ 樹的設計可以允許數(shù)據(jù)分批加載，同時樹的高度較低，提高查找效率。

HR 和小史簡單地聊了聊基本情況，這次面試就結束了。小史走后，面試官在系統(tǒng)中寫下了面試評語：

幾天后，小史收到了 A 廠的 Offer。