數據庫爲何要使用B+樹

今天看了幾篇文章，本身總結一下。

數據庫使用B+樹確定是爲了提高查找效率。

可是具體如何提高查找效率呢？

查找數據，最簡單的方式是順序查找。可是對於幾十萬上百萬，甚至上億的數據庫查詢就很慢了。

因此要對查找的方式進行優化，熟悉的二分查找，二叉樹能夠把速度提高到O(log(n,2))，查詢的瓶頸在於樹的深度，最壞的狀況要查找到二叉樹的最深層，因爲，每查找深一層，就要訪問更深一層的索引文件。在多達數G的索引文件中，這將是很大的開銷。因此，儘可能把數據結構設計的更爲‘矮胖’一點就能夠減小訪問的層數。在衆多的解決方案中，B-/B+樹很好的適合。B-樹定義具體能夠查閱，簡而言之就是中間節點能夠多餘兩個子節點，並且中間的元素能夠是一個域。相比B-樹，B+樹的父節點也必須存在於子節點中，是其中最大或者最小元素，B+樹的節點只存儲索引key值，具體信息的地址存在於葉子節點的地址中。這就使以頁爲單位的索引中能夠存放更多的節點。減小更多的I/O支出。所以，B+樹成爲了數據庫比較優秀的數據結構，MySQL中MyIsAM和InnoDB都是採用的B+樹結構。不一樣的是前者是非彙集索引，後者主鍵是彙集索引，所謂彙集索引是物理地址連續存放的索引，在取區間的時候，查找速度很是快，但一樣的，插入的速度也會受到影響而下降。彙集索引的物理位置使用鏈表來進行存儲。