MySQL 8.0.18 count(*) 比较慢的bug-技术圈

点击上方“服务端思维”，选择“设为星标”

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

作者 | yangyidba

出品 | yangyidba

一个之前的同事描述了他遇到的性能案例，两个数据库分别是 mysql 5.7 和 mysql 8.0 执行 select count(*) from table ，5.7 版本的性能明显好于 8.0 版本的。而且数据量 5.7 版本的300w ，8.0 版本的115w 左右。配置是RDS 1core2g .

分析

其实我自己没有怎么分析，查看了执行计划，是一致的。8.0.18 版本的确比较慢，于是谷歌之。。原因是官方针对 mysql 8.0.18 做一个改动: 如果buffer_pool 将近用完，并行扫描时涉及的到page几乎不会再进入到缓存，导致select count(*) 这种全表扫描每次都要物理读；同等情况下，MySQL 之前的版本比如 8.0.16 或者 5.7的版本可以进入加载更多的 page 到缓存，因此性能差别也就非常大。

官方的bug 地址 https://bugs.mysql.com/bug.php?id=99717&thanks=4

下图展示了 MySQL 8.0.18 版本执行count 动作时实例耗费的IOPS 的确飚的非常高。

如何解决

查看MySQL 8.0 Release Notes ，发现 8.0.20 和 8.0.26 分别解决了不同平台上的bug 。

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-26.html

InnoDB: Stalls were caused by concurrent SELECT COUNT(*) queries where the number of parallel read threads exceeded the number of machine cores. A patch for this issue was provided for Windows builds in MySQL 8.0.24. The MySQL 8.0.26 patch addresses the same issue on other affected platforms. (Bug #32678019) References: See also: Bug #32224707.

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-20.html

InnoDB: Changes to parallel read threads functionality introduced in MySQL 8.0.17 caused a degradation in SELECT COUNT(*) performance. Pages were read from disk unnecessarily. (Bug #30766089)

使用云RDS的朋友记得检查自己使用的数据库是否是大于8.0.17 的，看看该bug是否对自己的业务有什么影响。

— 本文结束 —

● 漫谈设计模式在 Spring 框架中的良好实践

● 颠覆微服务认知：深入思考微服务的七个主流观点

● 人人都是 API 设计者

● 一文讲透微服务下如何保证事务的一致性

● 要黑盒测试微服务内部服务间调用，我该如何实现？

关注我，回复「加群」加入各种主题讨论群。

对「服务端思维」有期待，请在文末点个在看

喜欢这篇文章，欢迎转发、分享朋友圈

在看点这里