1.到底innodb支不支持哈希索引呢？#
注意：收到几位朋友的email，给我提出建议：MEMORY、Heap、NDB支持哈希索引的。是的，但本文针对的是innodb — 更新2019.4.16
有人说支持，有人说不支持。在我看来，这两种说法都有部分道理。准确地说法应该是”innodb支持自适应哈希索引“。
包含层意思:
- 1 不能手动地创建哈希索引。通常，在mysql创建索引的时候，开发人员仅仅一句
create index ...就可以创建，但不无法创建哈希索引。
在这个角度分析的话，说不支持也有一定道理。 - 2 既然不然开发人员自主的创建哈希索引，那么要它何用？innodb会进行
self-tuning(自优化)。如果判断建立哈希索引，有助于提升查询性能。
那么InnoDB就会自己去建立相关哈希索引。在这个角度，分析InnoDB是支持哈希索引。
综述：innodb会自主的判断是否会加速查新效率，根据这个而自主创建的哈希索引不需要开发人员手动创建，称这种方式叫”自适应哈希索引”。
注：虽然不需要手动的创建哈希索引，但我们可以通过参数innodb_adaptive_hash_index是否禁用自适应哈希索引，默认是开启的。
当然，也可以通过show engine innodb status 查看当前的自适应哈希索引的状态。
2.自适应哈希索引是什么鬼？#
已经有了聚集索引、二级索引等等索引了，那自适应哈希索引又有什么用呢？没有场景，别技术。
下面我们分析一个查询的过程。以表employee为例，字段有id(主键),name,idcode(身份证号)等。建立在 idcode 字段上建立二级索引。
如果根据idcode 查询用户信息，在二级索引上查出主键；再根据主键回表查询聚集索引，才能获取数据。
注：这个示意图手画，有些简陋
你有没有感觉，记录定位的寻路路径(Search Path)很长呀，即便是聚集索引查询也是需要几次记录定位。innodb是这样解决这个问题的。
在MySQL运行的过程中，如果InnoDB发现，有很多SQL存在这类很长的寻路，并且有很多SQL会命中相同的页面(page)，InnoDB会在自己的内存缓冲区里，
开辟一块区域，建立自适应哈希所有AHI，以加速查询。
注：因为是哈希索引，所以不能范围查询，只能进行等值查询，即select colName1 from tableName where colName2=xxx