Percona 对 Percona Server for MySQL 8.4 的性能调查，聚焦于 2026 年发布的三个版本：8.4.8-8、8.4.10-10 和 8.4.11-11。这类跨小版本的对比很有价值：数据库升级通常不只是修复缺陷，也可能改变读写路径、并发行为或资源消耗。但版本号本身不能说明性能结论，真正需要比较的是一致工作负载下的吞吐、延迟与稳定性。
不要只看 QPS：读写性能有多个维度
对 MySQL 而言，“性能更好”至少可能指向几种不同变化：
- 在相同并发下，事务吞吐量（TPS）或查询吞吐量（QPS）更高。
- P95、P99 延迟下降，尾延迟更稳定。
- 写入压力下的日志刷新、checkpoint 或锁等待减少。
- 高并发读写混合场景中，扩展曲线更平缓，不会过早进入瓶颈。
- 性能没有明显提高，但 CPU、磁盘 I/O 或内存占用下降。
因此，比较 8.4.8-8、8.4.10-10 与 8.4.11-11 时，不能仅跑一次基准测试后取平均值。更可靠的做法是固定硬件、数据集、参数和客户端负载，分别记录吞吐、延迟分位数及服务端状态指标。
尤其需要区分两类场景：只读压测主要观察索引访问、缓存命中和连接并发；读写压测则会触及 InnoDB redo、buffer pool 脏页、checkpoint、锁竞争以及存储设备的 fsync 能力。一个版本在只读场景中表现更好，并不自动意味着它在重写入场景也更快。
三个版本应该如何建立可比基线
这项调查覆盖的版本发布时间如下：
| 版本 | 发布时间 |
|---|---|
8.4.8-8 |
2026-03-12 |
8.4.10-10 |
2026-06-30 |
8.4.11-11 |
2026-08-20 |
版本间隔只有数月，性能差异很可能小于不同机器、不同数据热度或一次后台 checkpoint 带来的波动。基准测试设计应优先控制这些变量：
- 使用同一台或同规格机器，并锁定 CPU governor、磁盘挂载参数和内核版本。
- 每个版本使用同一份初始化后的数据集，且数据量应明显大于 buffer pool，避免所有数据都被内存缓存掩盖差异。
- 固定 MySQL 配置，除非目标就是评估新版本推荐参数。
- 每个并发档位至少重复多次，报告中位数和离散程度，而非只报告最佳一次。
- 将预热与正式采样分开，避免冷缓存、连接建立和表初始化污染结果。
还有一个常见陷阱：升级后保留旧实例的数据目录直接压测。这样会把表统计信息、undo 状态、buffer pool 预热状态甚至遗留碎片一并带入实验。若目的是比较版本执行效率，可以这样实践：由同一初始化脚本为每个版本重建测试库；若目的是模拟真实升级，则应明确标注这是“升级后运行”的场景，而不是纯版本对比。
用 sysbench 跑出可复现的读写曲线
下面的示例假设测试机已安装 sysbench，三个 Percona Server for MySQL 实例均通过本机 3306 端口依次启动。请将 MYSQL_PASSWORD 改为测试账户密码，并确认账户拥有创建和操作 sbtest 数据库的权限。
先准备一个数据量足以产生实际 I/O 压力的表。--tables、--table-size 和 --threads 应按机器规格调整；示例数据规模仅用于展示流程。
export MYSQL_HOST=127.0.0.1
export MYSQL_PORT=3306
export MYSQL_USER=sbtest
export MYSQL_PASSWORD='change-me'
export MYSQL_DB=sbtest
sysbench oltp_read_write \
--mysql-host="$MYSQL_HOST" \
--mysql-port="$MYSQL_PORT" \
--mysql-user="$MYSQL_USER" \
--mysql-password="$MYSQL_PASSWORD" \
--mysql-db="$MYSQL_DB" \
--tables=16 \
--table-size=1000000 \
prepare
对每个版本分别执行预热和正式测试。这里选择 oltp_read_write，它会构造包含读取、更新、插入和删除的混合事务。--report-interval=10 会每 10 秒输出一次运行指标，便于发现测试中途的抖动。
sysbench oltp_read_write \
--mysql-host="$MYSQL_HOST" \
--mysql-port="$MYSQL_PORT" \
--mysql-user="$MYSQL_USER" \
--mysql-password="$MYSQL_PASSWORD" \
--mysql-db="$MYSQL_DB" \
--tables=16 \
--table-size=1000000 \
--threads=32 \
--time=60 \
--report-interval=10 \
--percentile=99 \
run
sysbench oltp_read_write \
--mysql-host="$MYSQL_HOST" \
--mysql-port="$MYSQL_PORT" \
--mysql-user="$MYSQL_USER" \
--mysql-password="$MYSQL_PASSWORD" \
--mysql-db="$MYSQL_DB" \
--tables=16 \
--table-size=1000000 \
--threads=32 \
--time=300 \
--report-interval=10 \
--percentile=99 \
run
建议将并发线程设置为一组阶梯值，例如 8、32、64、128。单一并发点只能说明局部表现；线程数递增后的 TPS 曲线和 P99 延迟曲线，才更容易暴露锁竞争、I/O 饱和或调度开销。
压测期间，可同时采集 InnoDB 状态。以下 SQL 可以直接在另一个连接中执行，用于定位吞吐变化到底来自数据库内部等待，还是已经受限于宿主机资源：
SHOW GLOBAL STATUS WHERE Variable_name IN (
'Threads_running',
'Threads_connected',
'Innodb_buffer_pool_reads',
'Innodb_buffer_pool_read_requests',
'Innodb_data_reads',
'Innodb_data_writes',
'Innodb_os_log_written',
'Innodb_row_lock_waits',
'Innodb_row_lock_time'
);
SHOW ENGINE INNODB STATUS;
如果某个版本 TPS 上升但 Innodb_row_lock_waits 同时显著增加，就不能简单判定它更优。它可能只是以更高吞吐换取了更差的尾延迟。反过来，吞吐小幅下降但 P99 明显收敛，在面向交互式请求的业务里也可能是更好的结果。
解读结果时，关注趋势而不是单点胜负
性能调查的核心不是给某个版本贴上“最快”标签，而是识别版本演进中的可重复趋势。一个实用的结果表至少应包含：版本、工作负载、并发数、TPS/QPS、平均延迟、P95/P99 延迟、CPU 利用率、磁盘延迟，以及测试轮次。
可以将结论按场景拆开表达，例如：
8.4.11-11在某个并发档位的混合读写 TPS 更高，但需要确认 P99 是否同步改善。- 某版本只读负载没有变化，而高并发写入的抖动减少，这通常比“平均 QPS 增长”更接近生产体验。
- 若三个版本差异落在重复测试的波动范围内，最诚实的结论是当前环境下没有观察到显著性能变化。
还要避免把实验室结果直接外推到生产。真实系统中的 SQL 分布、索引设计、事务长度、复制拓扑、磁盘介质和连接池策略，往往比数据库小版本差异更能决定性能。基准测试适合回答“该升级是否引入明显回归，以及哪些负载值得进一步验证”，而不是替代业务压测。
升级前的验证清单
将 Percona Server for MySQL 8.4 升级纳入发布计划前，可以用下面的清单收尾：
- 在与生产接近的数据规模和并发下，分别运行只读、混合读写和业务关键 SQL 测试。
- 记录 TPS/QPS，也记录 P95/P99 延迟和错误率。
- 重复运行测试，确认差异大于环境噪声。
- 检查 redo、checkpoint、锁等待和磁盘 I/O，解释指标变化的来源。
- 在预发布环境完成升级演练、回滚路径验证和监控基线更新。
8.4.8-8、8.4.10-10 与 8.4.11-11 的比较价值，不在于寻找一个脱离上下文的冠军版本，而在于为具体业务建立升级决策证据：性能是否回归、延迟是否稳定、资源余量是否仍然充足。这样得到的结论才能真正服务于上线窗口和容量规划。