爲何MySQL數據庫要用B+樹存儲索引？

問題：MySQL中存儲索引用到的數據結構是B+樹，B+樹的查詢時間跟樹的高度有關，是log(n)，若是用hash存儲，那麼查詢時間是O(1)。既然hash比B+樹更快，爲何mysql用B+樹來存儲索引呢？

答：1、從內存角度上說，數據庫中的索引通常時在磁盤上，數據量大的狀況可能沒法一次性裝入內存，B+樹的設計能夠容許數據分批加載。

2、從業務場景上說，若是隻選擇一個數據那確實是hash更快，可是數據庫中常常會選中多條這時候因爲B+樹索引有序，而且又有鏈表相連，它的查詢效率比hash就快不少了。

 

問題：爲何不用紅黑樹或者二叉排序樹？

答：樹的查詢時間跟樹的高度有關，B+樹是一棵多路搜索樹能夠下降樹的高度，提升查找效率

 

問題：既然增長樹的路數能夠下降樹的高度，那麼無限增長樹的路數是否是能夠有最優的查找效率？

答：這樣會造成一個有序數組，文件系統和數據庫的索引都是存在硬盤上的，而且若是數據量大的話，不必定能一次性加載到內存中。有序數組無法一次性加載進內存，這時候B+樹的多路存儲威力就出來了，能夠每次加載B+樹的一個結點，而後一步步往下找，

 

問題：在內存中，紅黑樹比B樹更優，可是涉及到磁盤操做B樹就更優了，那麼你能講講B+樹嗎？

B+樹是在B樹的基礎上進行改造，它的數據都在葉子結點，同時葉子結點之間還加了指針造成鏈表。

下面是一個4路B+樹，它的數據都在葉子結點，而且有鏈表相連。

問題：爲何B+樹要這樣設計？

答：這個跟它的使用場景有關，B+樹在數據庫的索引中用得比較多，數據庫中select數據，不必定只選一條，不少時候會選中多條，好比按照id進行排序後選100條。若是是多條的話，B+樹須要作局部的中序遍歷，可能要跨層訪問。而B+樹因爲全部數據都在葉子結點不用跨層，同時因爲有鏈表結構，只須要找到首尾，經過鏈表就能把全部數據取出來了。

 好比選出7到19只須要在葉子結點中就能找到。