MySQL 8.0.18 count(*) 比較慢的bug
點擊上方“服務端思維”，選擇“設為星標”
回復”669“獲取獨家整理的精選資料集
回復”加群“加入全國服務端高端社群「后端圈」
一個之前的同事描述了他遇到的性能案例，兩個數據庫分別是 mysql 5.7 和 mysql 8.0 執(zhí)行?select count(*) from table?，5.7 版本的性能明顯好于 8.0 版本的。而且數據量 5.7 版本的300w ，8.0 版本的115w 左右。配置是RDS 1core2g .
分析
其實我自己沒有怎么分析，查看了執(zhí)行計劃，是一致的。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 版本執(zhí)行count 動作時實例耗費的IOPS 的確飚的非常高。
如何解決
查看MySQL 8.0 Release Notes ，發(fā)現 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是否對自己的業(yè)務有什么影響。
— 本文結束 —
關注我，回復 「加群」 加入各種主題討論群。
對「服務端思維」有期待，請在文末點個在看
喜歡這篇文章，歡迎轉發(fā)、分享朋友圈
