点击
卡片，关注 InsideMySQL通过对于“祖先”版本的研究，一些想要入门数据库内核开发同学，可以快速对 MySQL 内核的底层架构有一个基本的理解。
毕竟研究 20W 行的代码，比研究 500W 行代码要轻松很多。某天，当继续徜徉在 3.23 源码的海洋中，突发奇想：如果将 MySQL 3.23 版本跑在最新的服务器上，会是什么样的结果呢？
测试服务器依然是之前 2 个带有超线程的 24核 CPU，总共 96 个逻辑 CPU。其实放现在也不算最新的 CPU ，只是核相对较多些：[david@jiangchengyao ~/]$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 96
On-line CPU(s) list: 0-95
Thread(s) per core: 2
Core(s) per socket: 24
Socket(s): 2
NUMA node(s): 2
接着还是通过 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 锁的优化不够充分，存在全局锁的问题。
trx_start
trx_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 差了好多倍，但是单核 CPU 的性能没有变呀？
MySQL 3.23 单核性能不输 MySQL 8.0，是不是没毛病？微信平台改变了推送规则，如果你还想看到我的文章，请一定给本文“点赞”、“在看”、“分享” 三连，新文章推送才会第一时间出现在你的微信里。认识这么久，我可不想丢掉你。IMG群是码农的交流社区，IMG微信群交流内容包括但不限于技术、经济、军事、八卦等话题。欢迎有态度的码农们加入IMG大家庭。IMG目前有少林群、武当群、峨眉群、华山群、M悦会（高端VIP群）。仅限码农入群，猎头或其他行业勿加，入群请加姜老师个人微信 82946772，并备注：码农入IMG群
