MySQL查询缓存与Innodb引擎的自适应哈希索引

查询缓存

执行过程

MySQL与引擎之间更像是两套体系，相互之间协同提供更好的数据服务，查询缓存是MySQL在8.0版本之前提供的一个特性，当客户端与数据库连接完毕，需要执行查询语句时，查询缓存就会发挥作用，MySQL会将查询语句进行对比，如果之前执行过该语句，执行语句和执行结果会以键值对的形式被直接缓存到内存里，因为使用查询语句作为key，MySQL可以用语句来查询对应的key，在缓存中找到的话，就可以将key对应value的值返回给客户端，少去了后来再通过分析器，优化器，执行器，引擎等各个阶段复杂的处理。

值得废弃

通过上面的执行过程就能看出一些问题，首先缓存语句的“范围”太大了，因为不同的语句可能会涉及很多复杂复合查询，简单粗暴的缓存起来的后果是，每当有对表的更新，这个表上所有的查询缓存都会被清空，如果是频繁更新的数据表，查询缓存的失效也会特别频繁，这时基本没有使用的意义了，查询缓存的意义更多是针对一些固定内容的表，或者是静态表，例如字典表或者配置表，但这样又有了新的问题，既然已经是固定的数据，那我们直接使用其他缓存数据库多好，查询效率快，也不用担心数据不一致的问题，为什么还要在MySQL中开启这个有些鸡肋的功能呢，所以查询缓存的功能被大大局限，原本的初衷是好的，但到了具体场景中，并没有达到预期的效果。

自适应哈希索引（Adaptive Hash Index）

索引条件

自适应哈希索引是Innodb的关键特性之一，其他特性还有诸如：

插入缓存
两次写
异步IO
刷新邻接页

自适应哈希索引位于innodb的缓存池中，属于单独的一块存储空间，不受LRU内存淘汰机制影响，之所以将查询缓存和哈希索引放一起说，因为他们的原理都是一样的，根据条件建立指定的键值对，下次查询可以通过键值对来直接获取结果，但自适应哈希索引做的更加细致，考虑到的场景也很多，innodb引擎对监控对表上各索引页的查询，如果观察到建立哈希索引可以提高查询速度，则建立哈希索引，索引的建立是通过构建缓存池里B+树页来的，不对整张表构建索引，所以速度很快。构建需要达到一定的条件：

通过一种固定模式的查询语句访问该页100次
页通过固定模式访问了N次，其中N=页中记录*1/16

访问模式可以是 where a=xxx，哈希索引只能用来搜索等值的查询，对于其他范围查询是不可以使用的，官方文档显示，启动自适应哈希索引，读取和写入速度可以提高2倍，辅助索引的连接操作性能可以提高5倍，之所以成为自适应，就是整个过程无需人为干预调整，完全由数据库自身来优化。还以为通过命令 show engine innodb status来查询当前哈希索引的使用情况。

索引优势

说完这些可以分析一下为什么自适应哈希索引要比查询缓存好，首先它细粒度化控制数据的缓存，而不是一步到位，只有满足条件才可以加索引缓存，它的使用范围也有限，只能在等值查询条件使用，也能进一步缩小缓存区间，最重要的是，它缓存的并不是数据内容，而是索引页，这样就不需要考虑数据更新的问题，索引页的更新，合并都有插入缓存这些特性来实现，哈希索引只要能保证快速链接到所要访问的索引页即可。