这篇博文将讨论innodb中的自适应哈希索引的用途，以及它是否适合你的工作负载。
adaptive hash index (ahi)是innodb中最难理解的特性之一。理论上，它会神奇地决定什么时候值得用快速哈希查找表来补充基于innodb b - tree的索引，然后在没有用户提示的情况下自动构建它们。
由于ahi被认为是“像魔术一样”工作的，它只有很少的配置可用。在早期版本中，根本没有可用的配置选项。之后的版本添加了innodb_adaptive_hash_index来禁用ahi(可以设置为0或off)。mysql 5.7通过启用innodb_adaptive_hash_index_parts增加了对ahi分区的能力。(仅供参考，该特性在percona server中从5.5版本起就以innodb_adaptive_hash_index_partitions的形式存在了。)
要理解ahi对性能的影响，可以把它当作一个缓存来考虑。如果发生了一个ahi“hit”，我们有更好的查找性能;如果是一个ahi " miss "，那么性能会稍微变差一些(因为检查哈希表的匹配速度很快，但不是免费的)。
这并不是等式的唯一部分。除了查找的成本之外，还有ahi维护的成本。我们可以比较维护成本(从添加和删除ahi的行数可以看出)和成功查找的成本。较高的比率意味着以较低的成本加快了许多查找。低比例意味着相反的情况:我们可能付出了太多的维护成本，却没有得到什么好处。
最后，添加额外的争用还需要付出代价。如果您的工作负载包含对大量索引或表的查找，您可以通过适当设置innodb_adaptive_hash_index_parts来减少影响。但是，如果存在热索引，那么ahi可能会成为高并发性的瓶颈，可能需要禁用。
为了确定ahi是否可能帮助我的工作负载，我们应该验证ahi命中和成功查找对维护操作的比率尽可能高。
让我们研究一下对于一些简单的工作负载实际会发生什么。我将根据主键使用基本的sysbench lookup—这是最简单的工作负载。我们会发现，即使在这种情况下，我们也会发现一些行为。
对于这个测试，我使用带有16gb缓冲池的mysql 5.7.11。sysbench的基本命令行是:
sysbench ‐‐test=/usr/share/doc/sysbench/tests/db/select.lua ‐‐report‐in terval=1 ‐‐oltp‐table‐size=1 ‐‐max‐time=0 ‐‐oltp‐read‐only=off ‐‐max‐reques ts=0 ‐‐num‐threads=1
‐‐rand‐type=uniform ‐‐db‐driver=mysql ‐‐mysql‐ password=password ‐‐mysql‐db=test_innodb run表中有1行数据测试
注意oltp-table-size=1;这不是一个错误，但测试了ahi在一个非常基本的情况下的行为:
而且它工作得很完美:100%的命中率，而且没有ahi维护操作。
表中有10000行测试
当我们将oltp表设置为oltp -table-size=10000时，我们得到如下图:
同样，我们几乎看不到头顶。有一个罕见的事件是16行左右添加到ahi(可能是由于ahi哈希冲突)。除此之外，它几乎是完美的。
表中有10m行测试
如果我们将oltp-table-size设置为10000000，我们现在有更多的数据(但仍然比缓冲池大小小得多):
在这种情况下，在接近100%命中率之前，显然有一个热身期——它从来没有完全达到100%(即使在较长的运行之后)。在这种情况下，维护操作似乎没有显示出渐近接近零的迹象。我的看法是，如果有10m行，那么哈希冲突的几率会更高，从而导致更多的ahi重建。
表中500m行测试
现在我们将oltp表的大小设置为:oltp -table-size=500000000。这将使数据的大小超过innodb缓冲池的大小。
在这里，我们看到很多缓冲池失误，导致非常糟糕的ahi命中率(从未达到1%)。我们还可以看到从ahi中添加/删除数万行的巨大开销。显然，在这种情况下，ahi并没有增加任何价值
表中500m行测试且pareto
最后，让我们使用设置oltp-table-size=500000000，并添加——rand-type=pareto。——rand-type=pareto设置支持倾斜分布，这是许多现实生活中的数据访问模式的更典型的场景
在这种情况下，我们看到ahi命中率逐渐提高，接近50%。ahi维护开销正在下降，但从来没有达到值得的程度。
值得注意的是，在上述两种情况下，ahi还没有达到“稳定状态”。稳态条件显示添加和删除的行数接近相等。
从上面的工作负载中你可以看到，innodb中的自适应哈希索引“魔法”并不总是发生!在某些情况下，ahi确实很有帮助，而在其他情况下，ahi增加了大量的数据结构维护开销，并从缓冲池中拿走了内存——更不用说争用开销了。在这些情况下，最好禁用ahi。
不幸的是，ahi似乎没有内置的逻辑来检测是否有太多的“波动”在进行，从而使得维护ahi是值得的。
我建议使用这些数字作为一般指南，以确定ahi是否可能有利于您的工作负载。确保运行测试/基准来确定。
原文标题：is adaptive hash index in innodb right for my workload?
原文作者：peter zaitsev
原文地址：https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload/