Hash結構
根據Hash函數的運算，只需經過一次定位，便能找到需要查詢數據所在的桶，不像B+樹索引，要從根節點到非葉子節點，再到葉子節點，最後才能訪問到我們的數據，這樣可能會經過多次的IO訪問，所以Hash索引的查詢效率理論上要高於B+樹索引。
如上這張圖，比如說我們要查找Sandra Dee這麼一個人，那麼根據Hash函數對Key，即Sandra Dee的運算，只需一次，我們便能定位到152號桶，就是這個buckets，之後便將152號的entries全部加載到內存當中，但由於該entries是一個鏈表，我們順著John Smith的指針，最終定位到Sandra Dee。
疑問
可能有些人就有疑問了，既然Hash索引的查詢效率要比B+樹高，為什麼我們不用Hash索引作為主流索引呢？任何事務都是有兩面性的，Hash索引也一樣，雖然Hash索引查詢效率高，但是Hash索引本身由於其特殊性也帶來了很多限制和弊端。
Hash索引的缺點：
1，僅僅能滿足“=”，“IN”，不能使用範圍查詢。
由於Hash索引比較的是進行Hash運算之後的Hash值，所以呢它只能用於等值的過濾，不能用於基於範圍的查詢，因為經過相應的Hash算法處理之後的Hash值的大小關係並不能保證和Hash運算前的完全一樣，如上圖，我們的Sandra Dee和John Smith就取了相同的Hash值了。
2，無法被用來避免數據的排序操作。
由於Hash索引中存放的是經過Hash運算之後的值，而且Hash值的大小關係並不一定和Hash運算前的鍵值完全一樣，所以數據庫無法利用索引的數據來避免任何排序運算。
3，不能利用部分索引鍵查詢。
對於組合索引，Hash索引在計算Hash值的時候，是組合鍵，就是將組合索引鍵合併之後再一起進行運算的Hash的值，而不是單獨計算Hash值的。所以呢通過組合索引的前面一個或幾個索引鍵進行查詢的時候，Hash索引也無法被利用，而B+樹是支持利用組合索引中的部分索引的。
4，不能避免表掃描。
Hash索引是將索引鍵通過Hash運算之後，將運算結果的Hash值和所對應的行指針信息存放在一個bucket當中的，由於不同索引鍵存在相同的Hash值，所以即使取出滿足某個Hash鍵值的那些數據，也無法從Hash索引中直接完成查詢，還是要通過訪問bucket中的實際數據進行相應的比較，這就是不能避免表掃描的原因。
5，遇到大量Hash值相等的情況後性能並不一定就會比B樹索引高。
對於選擇性比較低的索引鍵，如果創建Hash索引，那麼將會存在大量記錄指針信息存放於同一個bucket的情況，從而造成整體性能非常低下。就跟我們前面用到的二叉樹一樣，有可能會變成線性的存儲結構，有可能在一種很極端的情況下，所有的鍵計算出來的Hash值都是一樣的，也就是都放在同一個bucket中，那我們查詢bucket的最後一條數據的時候，就會變成線性的了，所以這也是Hash索引不能成為主流索引的原因，因為它比較的不穩定。
BitMap——位圖索引
當表中的某個字段只有幾種值得時候，就比如我們要表示性別的時候，只有男女兩種情況，如果僅僅是為了在這個字段上實現高效的統計，此時用位圖索引是一個最佳選擇了。不過很少有數據庫支持位圖索引，比較主流的是Oracle。
位圖索引的結構類似於B+樹，B+樹用來定位葉子節點，這些節點包含指定鍵值的位圖段，位圖段就位於葉子節點上，它的段信息就是下面的那些數字。
由於數據的值總類固定，像這裡只有Blue，Green，Red，Yellow四種，所以在存儲方式上，會先按照狀態值進行分開，然後每一種值的空間會存儲每個實際的數據行是否是這個值，我們可以看到這裡有0101這樣的位圖，比如第一行是Blue，我們就用1來表示，第二行不是就用0來表示。在這種情況下，由於只需要存儲“是”與“否”，所以通常只需要一個bit位來存放，因此理論上一個葉子塊，可以存放非常多的bit位，來表示不同的行，因此用它來統計時是非常快的，加載到內存中之後，幾乎是存cpu的疊加操作。
那位圖索引固然好，但是它只適用於某個字段的值只有固定的幾種情況，同時需要注意的是，位圖索引有一個很大的缺陷，就是它的鎖的力度非常大。當嘗試新增或修改一條數據的時候，通常與它在同一個位圖的數據操作都會被鎖住，因為某行所在的位置順序有可能會因為數據的添加或刪除而發生改變，所以它並不適合高併發的聯機事務處理系統，即咱們常見的OLTP系統，而適合於併發較少，而統計運算較多的OLAP（聯機分析處理）類系統。
閱讀更多 程序秀 的文章
