InnoDB到底支不支持哈希索引，为啥不同的人说的不一样？

继续回答水友提问（最近问 MySQL 的多）：

沈老师，我在网上看到不同的资料，有的说 InnoDB 支持哈希索引，有的说不支持，到底哪个是正确的呢？

对于 InnoDB 的哈希索引，确切的应该这么说：

（1）InnoDB 用户无法手动创建哈希索引，这一层上说，InnoDB 确实不支持哈希索引；

（2）InnoDB 会自调优 (self-tuning)，如果判定建立自适应哈希索引 (Adaptive Hash Index, AHI)，能够提升查询效率，InnoDB 自己会建立相关哈希索引，这一层上说，InnoDB 又是支持哈希索引的；

那什么是自适应哈希索引 (Adaptive Hash Index, AHI) 呢？原理又是怎样的呢？咱们先从一个例子开始。

不妨设有 InnoDB 数据表：

t(id PK, name KEY, sex, flag)

_画外音：_id 是主键，name 建了普通索引。

假设表中有四条记录：

1, shenjian, m, A

3, zhangsan, m, A

5, lisi, m, A

9, wangwu, f, B

如上图，通过前序知识，容易知道 InnoDB 在主键 id 上会建立聚集索引 (Clustered Index)，叶子存储记录本身，在 name 上会建立普通索引 (Secondary Index)，叶子存储主键值。

发起主键 id 查询时，能够通过聚集索引，直接定位到行记录。

select * from t where name='ls';

发起普通索引查询时：

（1）会先从普通索引查询出主键（上图右边）；

（2）再由主键，从聚集索引上二次遍历定位到记录（上图左边）。

不管聚集索引还是普通索引，记录定位的寻路路径 (Search Path) 都很长。

在 MySQL 运行的过程中，如果 InnoDB 发现，有很多 SQL 存在这类很长的寻路，并且有很多 SQL 会命中相同的页面 (page)，InnoDB 会在自己的内存缓冲区 (Buffer) 里，开辟一块区域，建立自适应哈希所有 AHI，以加速查询。

从这个层面上来说，InnoDB 的自使用哈希索引，更像 “索引的索引”，毕竟其目的是为了加速索引寻路。

既然是哈希，key 是什么，value 是什么？

key 是索引键值（或者键值前缀）。

value 是索引记录页面位置。

为啥叫 “自适应 (adaptive)****” 哈希索引？

系统自己判断 “应该可以加速查询” 而建立的，不需要用户手动建立，故称“自适应”。

系统会不会判断失误，是不是一定能加速？

不是一定能加速，有时候会误判。

当业务场景为下面几种情况时：

• 很多单行记录查询（例如 passport，用户中心等业务）
• 索引范围查询（此时 AHI 可以快速定位首行记录）
• 所有记录内存能放得下

AHI 往往是有效的。
_画外音：_任何脱离业务的技术方案，都是耍流氓。

当业务有大量 like 或者 join，AHI 的维护反而可能成为负担，降低系统效率，此时可以手动关闭 AHI 功能。
一个小知识点，希望解答了这位水友的疑问。
知其然，知其所以然。