自适应哈希索引(Adaptive Hash Index, AHI) 转

Adaptive Hash Index, AHI

场景

比如我们每次从辅助索引查询到对应记录的主键,然后还要用主键作为search key去搜索主键B+tree才能找到记录.

当这种搜索变多了,innoDB引擎会进行优化.

 

 

维护索引叶页面中所有记录的索引键值(或键值前缀)到索引叶页面位置的Hash映射关系,
能够根据索引键值(前缀)快速定位到叶页面满足条件记录的Offset，减少了B+树Search Path的代价，将B+树从Root页面至Leaf页面的路径定位，优化为Hash Index的快速查询。

Adaptive Hash Index是针对B+树Search Path的优化，因此所有会涉及到Search Path的操作，均可使用此Hash索引进行优化.

 

 

AHI还有一些要求，对这个页的连续访问模式必须是一样的。例如对于(a,b)这样的联合索引页，其访问模式可以是下面情况：

1. where a=xxx
2. where a =xxx and b=xxx

访问模式一样是指查询的条件是一样的，若交替进行上述两种查询，那么InnoDB存储引擎不会对该页构造AHI。 当然,访问模式一致,还必须达到一定的数量,比如页通过该模式访问了N次，其中N=页中记录*1/16.

一些资料统计,启用AHI后，读取和写入速度可以提高2倍，辅助索引的连接操作性能可以提高5倍。

AHI的设计思想是数据库自优化，不需要DBA对数据库进行手动调整,只能选择开启或者关闭。我们可以通过如下命令查看innodb AHI的使用情况.

mysql> show engine innodb status