MySQL 8.0.18 count(*) 比较慢的bug

一个之前的同事描述了他遇到的性能案例，两个数据库分别是 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是否对自己的业务有什么影响。

写这个文章的时候，看朋友圈开始发 8.0.27 release 的文章了。

hava fun with mysql