Percona Server 与 MySQL 官方版 thread pool 实测：2560 连接下 371 对 122 TPS，buffer pool 32G 后结论反转
来源：Thread Pool in Percona Server and MySQL (Part 2)，percona.com/blog，2026-10-12，作者 Bogdan Degtyariov。
Part 1 讲 thread pool 的概念、配置项，以及 Percona Server for MySQL 9.7.1-1 相对无 thread pool 基线的效率。Part 2 用 Percona Server 9.7.1-1 与 MySQL 26.7.0 / 9.7.2 做对比。
测试矩阵：buffer pool 取 2G / 12G / 32G，thread_pool_size 取 10 / 20 / 40 / 80 / 120 / 160，thread_pool_oversubscribe 取 2 / 3 / 4，客户端连接数取 640 / 1280 / 2560。
两个 MySQL 版本之间看不出差别
MySQL 26.7.0 与 9.7.2 的性能差异极小。无 thread pool 的配置两条线几乎重合，有 thread pool 时也一样，在 buffer pool 2G/12G/32G 与上述 thread_pool_size、thread_pool_oversubscribe 范围内都收敛到同一水平。只有高连接线程数下，26.7.0 略快于 9.7.2。所以下文的「MySQL」指的是官方实现的共同行为。
官方版 thread pool：高连接数才有收益
MySQL 官方版的 thread pool 行为与 Percona 不同：它不像 Percona 那样带来巨大提升，但在高客户端连接数（640 / 1280 / 2560）下，有 pool 的 TPS 明显好于无 pool。2560 连接时，pooled TPS 是非 pooled 的三倍——371 对 122。低并发时 thread pool 不会加分。
thread_pool_size 的最优值仍然重要，10 看起来和 Percona 一样是最优点；更高的 20 / 40 / 80 / 120 / 160 带来的 TPS 改善更少。与 Percona 不同，buffer pool=2G 时 thread_pool_oversubscribe 变化对 TPS 影响不大，但 2 比 3、4 略好。
同一组对比中，有 pool 的配置得到 18,975 TPS，无 pool 为 17,011，pool 赢 11.6%。MySQL 的 p95 特征与 Percona 类似，thread pool 把延迟从 759ms 降到 153ms。
| 场景 | TPS | p95 |
|---|---|---|
| MySQL 有 thread pool | 18,975 | 153ms |
| MySQL 无 thread pool | 17,011 | 759ms |
数据完全放得进 buffer pool 后，结论反过来
当数据集小到可以完全缓存（buffer pool=32G）时，两台服务器不开 pool 的性能接近，MySQL 略快；加上 thread pool 后 MySQL 明显胜出：19,054 TPS 对 Percona 15,519，差 22%。
p95 上 Percona 在 2G 和 12G 两档略好，32G 时 MySQL 领先；开启 thread pool 时 MySQL 的 p95 约好 25%，177ms 对 235ms。
| buffer pool=32G，开 thread pool | TPS | p95 |
|---|---|---|
| MySQL | 19,054 | 177ms |
| Percona Server | 15,519 | 235ms |
选型判断
两者共享基础代码，但 thread pool 的实现差别很大，结论随 buffer pool 是否够用而反转：
- 数据集大到无法完全缓存：Percona Server 的 thread pool 表现更好。
- 数据能完全缓存：MySQL 服务器及其 thread pool 胜出，p95 也略短。
- 无论选哪个，thread pool 只在连接数高时才值得开；连接数低时它不会加分。
- Percona 的 thread pool 对 thread groups（
thread_pool_size）与同组活跃线程数（thread_pool_oversubscribe）非常敏感，这两个选项对性能影响最大，需要调到最优值才能发挥潜力。