自适应哈希索引能够InnoDB
在具有适当的工作负载组合和足够的缓冲池内存的系统上更像内存数据库,而不会牺牲事务功能或可靠性。自适应哈希索引由
innodb_adaptive_hash_index
变量启用,或在服务器启动时由 关闭
--skip-innodb-adaptive-hash-index
。
基于观察到的搜索模式,使用索引键的前缀构建哈希索引。前缀可以是任意长度,也可能只是B树中的某些值出现在哈希索引中。哈希索引是针对经常访问的索引页面按需构建的。
如果一个表几乎完全适合主内存,则哈希索引通过启用对任何元素的直接查找来加速查询,将索引值转换为一种指针。
InnoDB
有一个监控索引搜索的机制。如果InnoDB
注意到查询可以从构建哈希索引中获益,它会自动这样做。
对于某些工作负载,哈希索引查找的加速大大超过了监视索引查找和维护哈希索引结构的额外工作。在繁重的工作负载(例如多个并发连接)下,访问自适应哈希索引有时会成为争用的源头。带有
LIKE
运算符和%
通配符的查询也往往不会受益。对于无法从自适应哈希索引中获益的工作负载,将其关闭可减少不必要的性能开销。由于很难提前预测自适应哈希索引功能是否适合特定系统和工作负载,因此请考虑在启用和禁用它的情况下运行基准测试。
在 MySQL 5.7 中,自适应哈希索引特性被分区。每个索引都绑定到一个特定的分区,每个分区都由一个单独的锁存器保护。分区由
innodb_adaptive_hash_index_parts
变量控制。在早期版本中,自适应哈希索引功能由单个锁存器保护,这在繁重的工作负载下可能成为争论的焦点。默认情况下,该
innodb_adaptive_hash_index_parts
变量设置为 8。最大设置为 512。
您可以在输出SEMAPHORES
部分
监视自适应哈希索引的使用和争用
。SHOW ENGINE INNODB
STATUS
如果有大量线程在等待创建的 rw-latches btr0sea.c
,请考虑增加自适应哈希索引分区的数量或禁用自适应哈希索引。
有关散列索引的性能特征的信息,请参阅第 8.3.8 节,“B 树和散列索引的比较”。