本文转载自MySQL原厂徐工的一篇文章,
原文链接如下:
https://mp.weixin.qq.com/s/_EXXmciNdgXswSVzKyO4xg
转文如下:
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,考虑使用查询重写或其他缓存。
文章至此。