震惊！MySQL 3.23版本跑在96核CPU，性能竟不输最新MySQL 8.0...

前面的文章《刚刚，我成功复活了 MySQL 祖先版本！》，姜老师已将 MySQL 3.23 版本在最新的 GCC 10.2 中编译并调试成功。

通过对于“祖先”版本的研究，一些想要入门数据库内核开发同学，可以快速对 MySQL 内核的底层架构有一个基本的理解。

毕竟研究 20W 行的代码，比研究 500W 行代码要轻松很多。

某天，当继续徜徉在 3.23 源码的海洋中，突发奇想：如果将 MySQL 3.23 版本跑在最新的服务器上，会是什么样的结果呢？

然后，就有了今天的跑分测试。

MySQL on 96 Core CPU

测试服务器依然是之前 2 个带有超线程的 24核 CPU，总共 96 个逻辑 CPU。其实放现在也不算最新的 CPU ，只是核相对较多些：

接着还是通过 sysbench 工具进行压测，测试依然选择主键查询。不过由于 MySQL 3.23 版本不支持 prepare statement 语句，这里需要通过参数 --db-ps-mode=disable 关闭编译缓存功能。最后压测的命令如下所示：

• sysbench /usr/share/sysbench/oltp_point_select.lua --time=1800 --mysql-db=test --tables=2 --table_size=1000000 --mysql-socket=/tmp/mysql.sock --mysql-user=root --report-interval=1 --threads=16 --db-ps-mode=disable run

发现测试的结果并不理想，16 线程下 QPS 仅有 14W 左右：

如果用命令 top 观察 CPU 使用率会发现对于多核的使用率并不高，仅使用了12个逻辑核：

此外，会发现 sy 的内核使用率与用户层的使用率差不多。这应该是 MySQL 3.23 锁的优化不够充分，存在全局锁的问题。

用 perf 命令可以验证：

展开可以看到 CPU 主要开销在以下几个函数：

• trx_starttrx_commit_for_mysql
• srv_conc_enter_innodb
• trx_assign_read_view
• row_search_for_mysql

这里的原因应该主要是 kernel_mutex 全局锁引起的，而这把锁是到 MySQL 5.6 才开始进行优化。

由于对多核支持不好，尝试将测试并发数调整为 8 ，这时性能提升较多，QPS 达到了25W，单核达到 3W QPS 的水准：

这时 CPU 使用率能达到近 8 个核，但是内核使用率依然较高：

若要继续优化，可以采用绑定 CPU 的方式，将 MySQL 3.23 的进程绑定在8个核上，并将测试的 sysbench 程序绑定到其他 CPU 上：

最终，可以看到这时 QPS 提升到 32W 的水准，这时单核 CPU 达到 4W QPS！

总结

通过本次测试可以看到 MySQL 3.23 可以非常稳定的运行在最新的多核服务器上。

然而，由于 kernel_mutex 的大锁的影响，MySQL 3.23 版本无法充分利用多核 CPU 以此提升数据库的整体性能。

通过降低压测并发数，减少锁冲突后，QPS 可以稳定在 32W。

咦？姜老师，标题不是说性能不输 MySQL 8.0 的么？

之前文章《QPS从20W到140W，一个参数让MySQL 8.0性能提升7倍》，MySQL 8.0 不是已经跑出 140W QPS 了么？

没错，总 QPS 差了好多倍，但是单核 CPU 的性能没有变呀？

MySQL 3.23 单核性能不输 MySQL 8.0，是不是没毛病？

所以，凭良心讲，姜老师是标题党么？欢迎留言评论。