MySQL 之 InnoDB引擎 Adaptive Hash index （自适应哈希索引）

官网解释

Adaptive Hash index（自适应哈希索引）的特性使得InnoDB在不牺牲事务特性或可靠性的前提下，为缓冲池提供适当的工作负载和足够的内存的时候，能够表现的更像 in-memory（内存）数据库。

该特性是通过变量innodb_adaptive_hash_index来使用的，可以说Adaptive Hash index不是传统意义的索引，可以理解为在Btree上的"索引"。

通过观测搜索模式，用索引键的前缀来构建哈希索引。前缀可以是任意长度，哈希索引根据经常需要访问的索引页面构建的。

如果一整个表都在主内存中，Hash Index可以通过直接查找任何元素加速查询，把索引值变成一种指针。InnoDB有个监控索引搜索的机制，如果查询可以从构建哈希索引受益就会自动执行该操作。

对于某些业务，Hash index查找的加速大大超过其成本例如（监听索引查找和维护索引结构的成本），在繁重的工作负载(例如多个并发连接)下，对adaptive hash index的访问有时会成为争用的来源。带着LIKE和%的查询不会受益。对于无法从adaptive hash index功能中受益的工作负载，将其关闭可减少不必要的性能开销。由于很难预先预测adaptive hash index功能是否适合特定系统和工作负载，因此请考虑在启用和禁用时运行基准测试。

在MySQL 5.7中，自适应哈希索引功能是分区的。每个索引都绑定到一个特定的分区，每个分区都由一个单独的锁存器保护。分区由innodb_adaptive_hash_index_parts 变量控制 （默认值 8，最大为512）。

 

通俗定义

简而言之，InnoDB本身不支持哈希索引，所有索引检索都走B树，Adaptive Hash index可以认为是“索引的索引”

（Btree上的"索引"）。当对某个页面访问次数满足一定条件会将页面地址存于Hash表，下次查询可以非常快速的找到页面不需要Btree去查。

（哈希索引：哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。）

AHI的目的是根据用户提供的查询条件加速定位到叶子节点，如果有固定的查询pattern，都可以通过AHI受益，特别是Btree深度比较大的时候。

 

AHI（Adaptive Hash index）使用条件

它的入口代码是这样的

/* Use of AHI is disabled for intrinsic table as these tables re-use
        the index-id and AHI validation is based on index-id. */
        if (rw_lock_get_writer(&btr_search_latch) == RW_LOCK_NOT_LOCKED
            && latch_mode <= BTR_MODIFY_LEAF
            && info->last_hash_succ
            && !index->disable_ahi
            && !estimate
# ifdef PAGE_CUR_LE_OR_EXTENDS
            && mode != PAGE_CUR_LE_OR_EXTENDS
# endif /* PAGE_CUR_LE_OR_EXTENDS */
            && !dict_index_is_spatial(index)
            /* If !has_search_latch, we do a dirty read of
            btr_search_enabled below, and btr_search_guess_on_hash()
            will have to check it again. */
            && UNIV_LIKELY(btr_search_enabled)
            && !modify_external
            && btr_search_guess_on_hash(index, info, tuple, mode,
                                        latch_mode, cursor,
                                        has_search_latch, mtr)) {

条件：

* btr_search_latch判断没加写锁。如果加了写锁，可能操作时间比较耗时，使用AHI检索记录就耗时多了；

* 打开了AHI

* atch_mode <= BTR_MODIFY_LEAF：这是一次不更改Btree结构的操作

* 不是spatial index

* info->last_hash_succ：最近一次Adaptive Hash index成功了

* 都满足进入该函数btr_search_guess_on_hash，根据当前的查询tuple对象计算fold，并进行AHI查询

 

问题

在某些负载下，AHI并不适合打开，关闭AHI可以避免额外的维护开销（为什么在上面官网说明有解释）。当然这取决于你针对具体负载的性能测试。如官网所说：由于很难预先预测adaptive hash index功能是否适合特定系统和工作负载，因此请考虑在启用和禁用时运行基准测试。

 

以上是对InnoDB引擎Adaptive Hash index的一些粗浅认识

 

转载请注明出处：

https://blog.csdn.net/qq_36652619