索引——hash

• 哈希索引（Hash Index）

  • 建立在哈希表的基础上，通过计算出被索引的哈希码实现
  • 只对列的精确查找有用
  • 它把哈希码保存在索引中，并且保存了一个指向哈希表中的每一行的指针。如果多个值有相同的哈希码，那么索引就会把行指针以链表的方式保存在哈希表的同一条记录中。

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

  • MySQL最常用存储引擎InnoDB和MyISAM都不支持HASH索引，它们默认的索引都是BTree。
  • 定义其索引类型为HASH，那么MySQL并不会报错，而且通过SHOW CREATE TABLE查看该索引也是HASH，只不过该索引实际上还是BTree
  • 若要使InnoDB或MyISAM支持哈希索引，那么可以通过伪哈希索引来实现。
    • 主要通过增加一个字段，存储HASH值，将HASH值建立索引，在插入和更新的时候，建立触发器，自动添加计算后的HASH值到表里。
    • 在查询的时候，在WHERE子句手动指定使用哈希函数。这样做的缺陷是需要维护哈希值。

• 优点

  • 检索效率非常高

    • 可以一次到位，不像BTREE索引需要从根节点到枝节点，最后才能访问到叶节点这样多次的I/O访问

  • 那么，既然HASH索引的效率要比BTREE高很多，为什么大家不都用HASH索引而还要使用BTREE索引呢？

    • 其实，任何事物都是有两面性的，虽然效率高，但是本身由于其特殊性也带来了很多限制和弊端

• 缺点

  • 仅能满足“=”、“IN”和“<=>”查询，不能使用范围查询。

    • 因为比较的是进行HASH运算之后的HASH值。

  • 优化器不能使用HASH索引来加速ORDER BY操作

    • 即HASH索引无法被用来避免数据的排序操作。因为HASH值的大小关系并不一定和HASH运算前的键值完全一样。

  • 只能使用整个关键字来搜索一行

    • 对于组合索引，在计算HASH值的时候是合并后再一起计算，而不是单独计算，所以通过组合索引的前面一个或几个索引键进行查询的时候，HASH索引也无法被利用。

  • 在任何时候都不能避免表扫描

    • 由于不同索引键存在相同HASH值，所以即使取满足某个HASH键值的数据的记录条数，也无法从HASH索引中直接完成查询，还是要访问实际数据进行比较。

  • 遇到大量HASH值相等的情况后性能并不一定就会比BTREE索引高。

    • 对于选择性比较低的索引键，会存在大量记录指针信息存于同一个HASH值相关联。这样要定位就非常麻烦，会浪费多次表数据的访问，造成整体性能低下。

  • 对于百万级别的大表，创建索引的速度很慢，耗时是btree的30多倍

• 总结

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