• 哈希索引（Hash Index）建立在哈希表的基础上，它只对使用了索引中的每一列的精确查找有用。

• 对于每一行，存储引擎计算出了被索引的哈希码（Hash Code），它是一个较小的值，并且有可能和其他行的哈希码不同。

• 它把哈希码保存在索引中，并且保存了一个指向哈希表中的每一行的指针。

• 如果多个值有相同的哈希码，那么索引就会把行指针以链表的方式保存在哈希表的同一条记录中。

• 只有MEMORY和NDB两种引擎支持哈希索引，MEMORY引擎默认支持哈希索引，

• 如果多个HASH值相同，出现哈希碰撞，那么索引以链表方式存储。

• 若要使InnoDB或MyISAM支持哈希索引，那么可以通过伪哈希索引来实现。

• 主要通过增加一个字段，存储HASH值，将HASH值建立索引，在插入和更新的时候，建立触发器，自动添加计算后的HASH值到表里。

• 在查询的时候，在WHERE子句手动指定使用哈希函数。这样做的缺陷是需要维护哈希值。

MySQL最常用存储引擎InnoDB和MyISAM都不支持HASH索引，它们默认的索引都是BTree。但是，如果在创建索引的时候定义其索引类型为HASH，那么MySQL并不会报错，而且通过SHOW CREATE TABLE查看该索引也是HASH，只不过该索引实际上还是BTree

hash索引的优点

HASH索引检索效率非常高，索引的检索可以一次到位，不像BTREE索引需要从根节点到枝节点，最后才能访问到叶节点这样多次的I/O访问，所以HASH索引的查询效率要远高于BTREE索引。那么，既然HASH索引的效率要比BTREE高很多，为什么大家不都用HASH索引而还要使用BTREE索引呢？其实，任何事物都是有两面性的，HASH索引也一样，虽然HASH索引效率高，但是HASH索引本身由于其特殊性也带来了很多限制和弊端

hash索引的缺点

1）HASH索引仅仅能满足“=”、“IN”和“<=>”查询，不能使用范围查询。由于HASH索引比较的是进行HASH运算之后的HASH值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的HASH算法处理之后的HASH值的大小关系，并不能保证和HASH运算前完全一样。

2）优化器不能使用HASH索引来加速ORDER BY操作，即HASH索引无法被用来避免数据的排序操作。由于HASH索引中存放的是经过HASH计算之后的HASH值，而且HASH值的大小关系并不一定和HASH运算前的键值完全一样，所以数据库无法利用索引的数据来减少任何排序运算量。

3）MySQL不能确定在两个值之间大约有多少行。如果将一个MylSAM表改为HASH索引的MEMORY表，那么会影响一些查询的执行效率。

4）只能使用整个关键字来搜索一行，即HASH索引不能利用部分索引键查询。对于组合索引，HASH索引在计算HASH值的时候是组合索引键合并后再一起计算HASH值，而不是单独计算HASH值，所以通过组合索引的前面一个或几个索引键进行查询的时候，HASH索引也无法被利用。

5）HASH索引在任何时候都不能避免表扫描。HASH索引是将索引键通过HASH运算之后，将HASH运算结果的HASH值和所对应的行指针信息存放于一个HASH表中，由于不同索引键存在相同HASH值，所以即使取满足某个HASH键值的数据的记录条数，也无法从HASH索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。

6）HASH索引遇到大量HASH值相等的情况后性能并不一定就会比BTREE索引高。对于选择性比较低的索引键，如果创建HASH索引，那么将会存在大量记录指针信息存于同一个HASH值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，从而造成整体性能低下。

总结

• 哈希表虽然快,但是并不适合作为Mysql的索引,因为mysql经常需要非等值查询