在之前的博文中我们探讨了一种常见的索引类型：B-Tree索引。这里我们继续来讨论另一种索引类型：哈希索引。
哈希索引
哈希索引基于哈希表实现，只有精确匹配索引的所有列的查询才有效，这是非常重要的一点。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码，哈希码是一个较小的值，并且不同的键值行计算出的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。
在MySQL中，只有Memory引擎显式支持哈希索引，这也是Memory引擎的默认索引类型。Memory引擎也同时支持B-Tree索引，值得一提的是，Memory引擎是支持非唯一哈希索引的。如果多个列的哈希值相同，索引会以链表的方式存放多个记录指针到同一个哈希条目中。
我们直接来看一个例子，假设有下表：
CREATE TABLE (
fname VARCHAR(50) NOT NULL,
lname VARCHAR(50) NOT NULL,
KEY USING HASH(fname)
)ENGINE=MEMORY;表中包含如下数据：
1SELECT * FROM testhash;
| fname | lname |
| Arjen | Lentz |
| Baron | Schwartz|
| Peter | Zaitsev |
假设索引使用家乡的哈希函数f()，它返回下面的值：
f(‘Arjen’)=2323
f(‘Baron’)=7437
f(‘Peter’)=8784
则哈希索引的数据结构如下：
| Slot | Value |
| 2323 | 指向第1行的指针 |
| 7437 | 指向第2行的指针 |
| 8784 | 指向第3行的指针 |
槽中的编号是顺序的，但是数据行不是。
现在有如下查询：1SELECT lname FROM testhash WHERE fname='Peter';
MySQL会先计算‘Peter’的哈希值，并使用该值找到对应的记录指针。因为f(‘Peter’)=8784，所以MySQL在索引中查找8784，可以找到指向第3行的指针。最后一步是比较第三行的值是否为‘Peter’，以确保就是要查找的行。
因为索引自身只存储对应的哈希值，所以索引的结构十分紧凑，这也让哈希表索引查找的速度非常快。然而哈希索引也有他的限制：哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。
哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序。
哈希索引也不支持部分索引列匹配查找，因为哈希索引始终是使用索引列的全部内容来计算哈希值的。
哈希索引只支持等值比较查询，包括=、IN()、<=>，也不支持任何范围查询。
访问哈希索引的速度非常快，除非有很多哈希冲突。
如果哈希冲突很多的话，一些索引维护曹锁的代价也会很高。
InnoDB有一种特殊的功能叫做“自适应哈希索引”。当InnoDB注意到某些索引值被使用的非常频繁时，它会在内存中基于B-Tree索引之上再创建一个哈希索引，这样就让B-Tree索引也具有哈希索引的一些优点，比如快速的哈希查找，这是一个完全自动的内部行为，用户无法控制或者配置。
