b+tree和普通的b-tree不大一樣。有個**可以體驗這些資料結構：
先看一下b-tree
設定最大深度為3，插入10個數字，資料結構如上，他與普通的二叉樹區別在於每個節點有多個資料，相當於橫向擴充套件，減少深度。
為什麼要減少深度：當資料量比較大的時候，mysql無法將索引全部載入到記憶體中，只能逐一載入磁碟頁，每個磁碟頁對應樹的節點。造成大量磁碟ｉｏ操作（最壞情況下為樹的高度）。平衡二叉樹由於樹深度過大而造成磁碟io讀寫過於頻繁，進而導致效率低下。所以，我們為了減少磁碟ｉｏ的次數，就你必須降低樹的深度，將「瘦高」的樹變得「矮胖」。
b樹在這一點上已經比二叉樹先進很多了，但對比b+樹還是差了點，為了更好說明b+樹，需要提到的是在mysql中，b數的節點中都帶有儲存資料。
可以看到兩個特點：
1.同樣是三層資料，但是這裡多了一層資料層，那是因為，b+樹只有最後的葉子節點才會帶有資料，其他的都是索引。
2.資料間帶有乙個指標
這些特點有什麼用呢？
1.在mysql的b樹索引方式中，每個節點的儲存容量是固定的，如果節點中儲存了資料，意味著，該節點只能儲存更少的索引，這將導致查詢資料時需要經過更多的io，反過來，b+樹可以更快找到對應的資料
2.ｂ樹的查詢只需找到匹配元素即可，最好情況下查詢到根節點，最壞情況下查詢到葉子結點，所說效能很不穩定，而ｂ＋樹每次必須查詢到葉子結點，效能穩定
3.在範圍查詢方面，b+樹的優勢更加明顯。b樹的範圍查詢需要不斷依賴中序遍歷。首先二分查詢到範圍下限，在不斷通過中序遍歷，知道查詢到範圍的上限即可。整個過程比較耗時。而b+樹的範圍查詢則簡單了許多。首先通過二分查詢，找到範圍下限，然後同過葉子結點的鍊錶順序遍歷，直至找到上限即可，整個過程簡單許多，效率也比較高。
比如，當查詢索引值大於某個數值時，根據資料節點的向後指標，b+樹只要找到臨界點後，直接可以找到後面的所有資料，而不用回到根節點上再去查詢。
雜湊索引是基於雜湊表實現的，只有精確匹配索引所有的列的查詢才有效。對於每一行資料，儲存引擎都會對所有的索引列計算乙個雜湊碼，雜湊碼是乙個較小的值，並且不同鍵值的行計算出來的雜湊碼也不一樣。雜湊索引是將所有的雜湊碼儲存在索引中，同時在雜湊表中儲存指向每個資料行的指標。
在mysql中，只有memory 引擎顯示支援雜湊索引。這也是memory 引擎表的預設索引型別，memory 引擎同時也支援b-tree索引。這裡插播乙個mysql的儲存引擎，如果涉及到索引的型別的設計，還是有必要參考一下的
可以主要到，如果需要支援外來鍵的話，那基本只能選擇innodb型別。
回到主題，當採用了hash索引之後，在資料庫中根據索引查詢乙個記錄時非常快的事情：
1.根據索引值計算hash，速度極快
2.根據hash值獲取儲存位址，速度極快
3.根據儲存位址獲取資料，速度極快
hash索引雖然查詢快，但是那僅限於精確查詢，他的缺陷同樣不小：
雜湊索引只包含雜湊值和行指標，而不儲存字段值，所以不能上使用索引中的值來避免讀取行。
雜湊索引資料並不是按照索引值順序儲存的，所以也就無法用於排序。
雜湊索引也不支援部分索引列匹配查詢，因為雜湊索引始終是使用索引列的全部內容來計算雜湊值的。
雜湊索引只支援等值比較查詢，包括=、in( )、<=>（注意<>和<=>是不同的操作）。也不支援任何範圍查詢，如 where price > 100 ;
訪問雜湊索引的資料結構非常快，除非有許多雜湊衝突
如果雜湊衝突很多，一些索引維護操作的代價也會很高。
MySQL的btree索引和hash索引的區別
hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像b tree 索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的io訪問，所以 hash 索引的查詢效率要遠高於 b tree 索引。可 能很多人又有疑問了，既然 hash 索引的效率要比 b tree 高很多，為什麼大...
MySQL的btree索引和hash索引的區別
hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像b tree索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的io訪問，所以 hash 索引的查詢效率要遠高於 b tree索引。可能很多人又有疑問了，既然hash 索引的效率要比 b tree 高很多，為什麼大家不都用...
MySQL的btree索引和hash索引的區別
原文 hash 索引結構的特殊性，其檢索效率非常高，索引的檢索可以一次定位，不像b tree 索引需要從根節點到枝節點，最後才能訪問到頁節點這樣多次的io訪問，所以hash 索引的查詢效率要遠高於 b tree 索引。可 能很多人又有疑問了，既然 hash 索引的效率要比 b tree 高很多，為什...