MySQL之前有一个查询缓存Query Cache,从8.0开始,不再使用这个查询缓存,那么放弃它的原因是什么呢?在这一篇里将为您介绍。

MySQL查询缓存是查询结果缓存。它将以SEL开头的查询与哈希表进行比较,如果匹配,则返回上一次查询的结果。进行匹配时,查询必须逐字节匹配,例如 SELECT * FROM t1; 不等于select * from t1;,此外,一些不确定的查询结果无法被缓存,任何对表的修改都会导致这些表的所有缓存无效。因此,适用于查询缓存的最理想的方案是只读,特别是需要检查数百万行后仅返回数行的复杂查询。如果你的查询符合这样一个特点,开启查询缓存会提升你的查询性能。

随着技术的进步,经过时间的考验,MySQL的工程团队发现启用缓存的好处并不多。

首先,查询缓存的效果取决于缓存的命中率,只有命中缓存的查询效果才能有改善,因此无法预测其性能。

其次,查询缓存的另一个大问题是它受到单个互斥锁的保护。在具有多个内核的服务器上,大量查询会导致大量的互斥锁争用。

通过基准测试发现,大多数工作负载最好禁用查询缓存(5.6的默认设置):query_cache_type = 0

如果你认为会从查询缓存中获得好处,请按照实际情况进行测试。

  • 数据写的越多,好处越少
  • 缓冲池中容纳的数据越多,好处越少
  • 查询越复杂,扫描范围越大,则越受益

MySQL8.0取消查询缓存的另外一个原因是,研究表明,缓存越靠近客户端,获得的好处越大。关于这份研究请参考https://proxysql.com/blog/scaling-with-proxysql-query-cache/

下图源自上面的网址:

除此之外,MySQL8.0新增加了对性能干预的工具,例如,现在可以利用查询重写插件,在不更改应用程序的同时,插入优化器提示语句。另外,还有像ProxySQL这样的第三方工具,它们可以充当中间缓存。

综合以上原因,MySQL8.0不再提供对查询缓存的支持,如果用户从5.7版本升级至8.0,考虑使用查询重写或其他缓存。

全文完。

更多相关文章

  1. JNI 无法确定Bitmap的签名
  2. android webview 中网页数据与js交互
  3. Android(安卓)学习 设备管理器勾选后不能再取消了
  4. Android(安卓)3.0之后开机无法接收系统广播权限原因
  5. Android(安卓)Studio编译报Default interface methods are only
  6. ListView setOnItemClickListener无效原因详细分析
  7. ListView setOnItemClickListener无效原因分析
  8. ListView setOnItemClickListener无效原因详细分析
  9. Android常见错误处理

随机推荐

  1. 太强了!这款轻量级的数据库中间件完美解决
  2. 更轻量级的 V8 引擎[每日前端夜话0xC8]
  3. JavaScript中的异步生成器函数[每日前端
  4. 编码与编程的区别是什么?[每日前端夜话0xC
  5. 太强了!这两款数据库中间件,完美解决 Sprin
  6. Spring Boot 项目中的三种多数据源方案,一
  7. 丢弃掉那些 BeanUtils 工具类吧,MapStruct
  8. 用 NodeJS 充分利用多核 CPU 的资源[每日
  9. IDEA + Spring Boot 的三种热加载方案,看
  10. 用 cURL 请求测试 ETag 浏览器缓存[每日