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