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

By | 2021年3月16日

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来查询当前哈希索引的使用情况。

索引优势

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注