15.4.3 Adaptive Hash Index
(自适应哈希索引)
The adaptive hash index (AHI) lets InnoDB perform more like an in-memory database on systems with appropriate combinations of workload and ample memory for the buffer pool, without sacrificing any transactional features or reliability. This feature is enabled by the innodb_adaptive_hash_index option, or turned off by --skip-innodb_adaptive_hash_index at server startup.
自适应哈希索引(AHI)使InnoDB平台看起来更像一个内存数据库(在系统负载适当并且分配给缓存池的
内存
充裕的情况下),且不牺牲任何事务特性或可靠性。这个特性可以在服务启动时通过innodb_adaptive_hash_index选项生效,或者通过--skip-innodb_adaptive_hash_index关闭。
Based on the observed pattern of searches, MySQL builds a hash index using a prefix of the index key. The prefix of the key can be any length, and it may be that only some of the values in the B-tree appear in the hash index. Hash indexes are built on demand for those pages of the index that are often accessed.
根据所观察到的的搜索模式,MySQL用一个索引键的前缀建立一个哈希索引。该键的前缀可以是任意长度,并且只有B-tree中的少数值才会出现在哈希索引中。哈希索引是为了获取那些被频繁访问的索引页而建立的。
If a table fits almost entirely in main memory, a hash index can speed up queries by enabling direct lookup of any element, turning the index value into a sort of pointer. InnoDB has a mechanism that monitors index searches. If InnoDB notices that queries could benefit from building a hash index, it does so automatically.
如果一张表几乎整个被至于主内存中,那么有了哈希索引就可以直接查找任意元素并将其索引值转换为一系列的指针从而提升查询速度。InnoDB有一个机制可以监控索引的搜索。如果InnoDB注意到查询可以通过建立哈希索引得到优化,那么他就会自动做这件事。
With some workloads, the speedup from hash index lookups greatly outweighs the extra work to monitor index lookups and maintain the hash index structure. Sometimes, the read/write lock that guards access to the adaptive hash index can become a source of contention under heavy workloads, such as multiple concurrent joins. Queries with LIKE operators and % wildcards also tend not to benefit from the AHI. For workloads where the adaptive hash index is not needed, turning it off reduces unnecessary performance overhead. Because it is difficult to predict in advance whether this feature is appropriate for a particular system, consider running benchmarks with it both enabled and disabled, using a realistic workload. The architectural changes in MySQL 5.6 and higher make more workloads suitable for disabling the adaptive hash index than in earlier releases, although it is still enabled by default.
只需增加少量负载,这种由于哈希索引查询所带来的速度提升大大超过监控索引查询和维护哈希索引结构的所带来的额外工作量。有时,在高负载的情况下守护自适应哈希索引访问的读写锁会变成一种竞争资源,例如多重并发关联。基于LIKE操作和%通配符的查询也往往不通过AHI来优化。对于自适应哈希索引所不需要的负载,关闭它以节省不必要的性能开销。由于难以提前预测该特性是否适用于某一特定系统,需要在实际负载下,识别在其启用和禁用时的运行指标。该架构在MySQL 5.6及以上版本中改变,
相比之前的版本,
禁用自适应哈希索引会适当的产生更多的负载。
As of MySQL 5.7.8, the adaptive hash index search system is partitioned. Each index is bound to a specific partition, and each partition is protected by a separate latch. Partitioning is controlled by the innodb_adaptive_hash_index_parts configuration option. Prior to MySQL 5.7.8, the adaptive hash index search system was protected by a single latch which could become a point of contention under heavy workloads. The innodb_adaptive_hash_index_parts option is set to 8 by default. The maximum setting is 512.
从MySQL 5.7.8开始,自适应哈希索引搜索系统是分区的。每个索引都会绑定到一个特殊的分区上,并且每个分区都由各自独立的锁存器来保护。分区受到innodb_adaptive_hash_index_parts配置项的控制。在MySQL5.7.8之前,自适应哈希索引搜索系统是通过一个单独的锁存器来保护,在高负载的情况下它会变成竞争点。innodb_adaptive_hash_index_parts选项默认值为8,最大值为512。
The hash index is always built based on an existing B-tree index on the table. InnoDB can build a hash index on a prefix of any length of the key defined for the B-tree, depending on the pattern of searches that InnoDB observes for the B-tree index. A hash index can be partial, covering only those pages of the index that are often accessed.
哈希索引的建立总是基于表上的一个现有的B-tree索引。InnoDB可以用任意长度的B-tree键的前缀建索引,依赖于InnoDB从B-tree索引上所观察到的搜索模式。哈希索引可以是局部的,仅覆盖哪些经常被访问的索引页。
You can monitor the use of the adaptive hash index and the contention for its use in the SEMAPHORES section of the output of the SHOW ENGINE INNODB STATUS command. If you see many threads waiting on an RW-latch created in btr0sea.c, then it might be useful to disable adaptive hash indexing.
你可以通过SHOW ENGINE INNODB STATUS命令所输出的SEMAPHORES部分来监控自适应哈希索引的使用及其竞争情况。如果你看到许多线程正在等待一个在btr0sea.c中创建的RW-latch,然后它可能被用于禁用自适应哈希索引。
For more information about the performance characteristics of hash indexes, see Section 9.3.8, “Comparison of B-Tree and Hash Indexes”.
更多信息关于哈希索引的性能特性,请参考9.3.8,“B-Tree和哈希索引的竞争”。