B-Tree
B-Tree索引適用於全鍵值、鍵值範圍或鍵前綴查找。其中鍵前綴查找只適用於根據最左前綴的查找。
全值匹配
匹配最左前綴
匹配列前綴
匹配範圍值
精確匹配某一列並範圍匹配另外一列
只訪問索引的查詢
因爲索引樹種的節點是有序的，所以除了按值查找之外，索引還可以用於查詢中的ORDER BY操作。
下面是一些關於B-Tree索引的限制：
如果不是按照索引的最左列開始查找，則無法使用索引。
不能跳過索引中的列。（也就是說，不能越過第一個索引列而使用之後的索引列）
如果查詢中有某個列的範圍查詢，則其右邊所有列都無法使用索引優化查詢。
所以索引和列的順序是有關係的。
哈希索引
哈希索引是基於hash表實現的。因爲hash索引自身只需要存儲對應的哈希值，所以索引的結構非常緊湊，這樣是hash索引速度非常快的原因。然而哈希索引也有它的限制：
哈希索引無法用於排序
哈希索引不支持部分匹配查詢
哈希索引只支持等值查詢
哈希索引速度非常快，除非有很多衝突哈希索引
如果衝突大的話，一些索引的維護代價也很高
創建自定義哈希索引
思路很簡單：在B-Tree基礎上創建一個僞哈希索引。這和真正的哈希索引不是一回事，因爲還是使用B-Tree進行查詢，但是它使用哈希值而不是鍵本身進行索引查找。你需要做的是在where子句中手動指定使用哈希函數。下面是一個實例，需要存儲大量的URL，並需要根據URL進行搜索查詢。
正常查詢應該是這樣：select id from url where url="http://3157689.blog.51cto.com/"
若刪除原來URL列上的索引，而新增一個被索引的url_crc列，使用CRC32做哈希，就可以使用這種方式查詢：select id from url where url='http://3157689.blog.51cto.com/' and url_crc=CRC32('http://3157689.blog.51cto.com/')
空間數據索引（R-Tree）
MyISAM表支持空間索引，可以用作地理數據存儲。這類索引無須前綴查詢。空間索引會從所有維度來索引數據。
全文索引
它查找的是文本中的關鍵詞，而不是直接比較索引中的值。全文索引適用於MATCH AGAINST操作，而不是普通的WHERE條件操作。
索引是最好的解決方案嗎？
索引並不總是最好的工具。總的來說，只有當索引幫助存儲引擎快速查找到記錄帶來的好處大於其帶來的額外工作時，索引纔是有效的。對於非常小的表來說，全表掃描更高效。對於中到大型的表，索引就非常有效。但對於特大的表，建立和使用索引的代價將隨之增長。這種情況下，則需要一種技術可以直接區分出查詢需要的一組數據，而不是一條記錄一條記錄地匹配。例如可以使用分區技術。