MySQL: Hash索引

1.介绍

1.innodb本身的索引结构是B+tree，而hash索引是innodb存储引擎提供的特性功能
2.innodb存储引擎内部自己去监控索引表，如果监控到某个索引经常用，那么就认为是热数据，然后内部自己创建一个hash索引（只适用“=”的查询，对“in”“<=>”这些范围查询不适用）
3.创建了hash索引后，如果下次又查询到这个索引，那么直接通过hash算法推导出记录的地址，直接一次就能查到数据，比重复去B+tree索引中查询三四次节点的效率高了不少

哈希索引

针对上图的理解：

• keys：代表创建索引的列值；
• buckets： 就是计算出来的hash值和对应的数据的物理位置组成的hash表；
• entries：就是代表具体的数据行；
• 创建hash索引后，会为每个键值通过特定的算法计算出一个哈希码（hash code)，需要注意的是不同的键值计算出来的hash值可能是相同的，例上图上的 John Smith 和Sandra Dee算出来的hash值都是152，然后找到hash值为152在hash表中的存储数据的物理位置，这个位置对应着两条数据也(就是John Smith 521-1234 和Sandra Dee 521-9655)，然后再次遍历这两条数据，找到需要的数据，这就解释了为啥hash冲突严重了，hash索引效率降低的原因。
  hash索引检索数据的过程（摘杂网络）
  当我们为某一列或某几列建立hash索引时（目前就只有MEMORY引擎显式地支持这种索引），会在硬盘上生成类似如下的文件：

hash值即为通过特定算法由指定列数据计算出来，存储地址即为所在数据行存储在硬盘上的地址（也有可能是其他存储地址，其实MEMORY会将hash表导入内存）。
这样，当我们进行WHERE age = 18 时，会将18通过相同的算法计算出一个hash值==>在hash表中找到对应的储存地址==>根据存储地址取得数据==>最后一步确定这行数据是否是需要查询的数据。
所以，每次查询时都要遍历hash表，直到找到对应的hash值，数据量大了之后，hash表也会变得庞大起来，性能下降，遍历耗时增加；

Hash索引的优缺点

优点：

因为索引自身只需存储对应的哈希值，所以索引的结构十分紧凑，这也让哈希索引查找的速度非常快

缺点：

1、不能避免读取行

哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行。不过，访问内存中的行的速度很快，所以大部分情况下这一点对性能的影响并不明显。

2、无法用于排序

哈希索引数据并不是按照索引值顺序存储的，所以也就无法用于排序。

3、无法使用部分索引列匹配查找

哈希索引也不支持部分索引列匹配查找，因为哈希索引始终是使用索引列的全部内容来计算哈希值的。例如，在数据列（A,B）上建立哈希索引，如果查询只有数据列A，则无法使用该索引。

4、只支持等值查找

哈希索引只支持等值比较查询，包括=、IN()、<=>（注意<>和<=>是不同的操作）。也不支持任何范围查询，例如WHERE price>100。

5、存在Hash冲突

访问哈希索引的数据非常快，除非有很多哈希冲突（不同的索引列值却有相同的哈希值）。当出现哈希冲突的时候，存储引擎必须遍历链表中所有的行指针，逐行进行比较，直到找到所有符合条件的行。

同时，当哈希冲突很多的时候，一些索引维护操作的代价也会很高。例如，如果在某个选择性很低（哈希冲突很多）的列上建立哈希索引，那么当从表中删除一行时，存储引擎需要遍历对应哈希值的链表中的每一行，找到并删除对应行的引用，冲突越多，代价越大。

综上，Hash索引只适用于某些特定的场景（也就是说实际使用中用得非常少-_-!）

自适应哈希索引

InnoDB 存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引。
查看当前自适应哈希索引的使用状况：ON表示开启自适应哈希索引

SHOW VARIABLES LIKE '%ap%hash_index';