MySQL社区版原生不支持线程池，仅Enterprise或Percona Server提供；Percona中thread_pool_size建议设为CPU核心数（上限16），且需配置文件重启生效；开启后变慢常见于超时设置过大、长事务阻塞或队列积压。
MySQL 线程池到底要不要开？
MySQL 官方版本（5.5+）默认不启用线程池，thread_pool_size、thread_pool_max_threads 等参数根本不存在——它们只在 Oracle MySQL Enterprise Edition 或 Percona Server 中提供。社区版 MySQL（如 mysql-community-server）原生不支持线程池，强行查 SHOW VARIABLES LIKE '%thread_pool%' 会返回空。如果你用的是社区版，别折腾配置了，先换内核或换方案。
Percona Server 下 thread_pool_size 怎么设？
thread_pool_size 控制内部调度组数量，不是“最大并发数”。它影响的是线程复用粒度和锁竞争：值太小（如 1），所有连接排队争一个调度器，高并发时延迟飙升；值太大（如 > CPU 核心数 × 2），调度开销上升，上下文切换变多。实际建议按物理 CPU 核心数设置：
- 单实例、无其他重负载：设为
min(16, CPU核心数) - 多实例共存或有 CPU 限制（如容器）：设为
ceil(CPU配额 / 2) - OLTP 主库且 QPS > 5k：可试
8~12，配合thread_pool_stall_limit=50（毫秒）防长事务阻塞调度
注意：thread_pool_size 是只读变量，必须写进 my.cnf 并重启生效，SET GLOBAL 不起作用。
为什么开了线程池反而慢？常见陷阱
线程池不是银弹，以下情况会明显劣化性能：
-
wait_timeout或interactive_timeout设得过大（如 28800 秒），空闲连接长期占着线程槽位，新请求被卡在队列尾部 - 存在未提交的长事务（
TRX_STATE = 'LOCK WAIT'或运行超 10s 的SELECT），它会独占一个 worker 线程，导致同组其他请求无限等待 -
thread_pool_max_threads过低（默认 64），而活跃连接数持续 > 80，大量请求进入QUEUED状态，监控看Threads_running很低但Threads_connected很高 - 开启了
slow_query_log且日志刷盘慢，每个慢查询都会拖慢整个调度组——线程池里是“组内串行记录 slow log”
查当前队列积压：执行 SELECT * FROM information_schema.THREAD_POOL_GROUPS，重点关注 QUEUED 和 THREADS 列是否持续不均衡。
比线程池更现实的替代方案
如果你用的是社区版 MySQL，或上线后发现线程池调参成本太高，优先考虑这些更可控的手段：
- 应用层加连接池（如 HikariCP 的
maximumPoolSize控制在 20~50），比数据库线程池更容易观测和限流 - 用
max_connections+wait_timeout组合做硬隔离，避免雪崩式连接打满 - 对慢查询强制加
MAX_EXECUTION_TIME=3000（MySQL 5.7.8+），防止单个语句卡死调度组 - 升级到 MySQL 8.0+ 后，关注
innodb_thread_concurrency和后台线程（如innodb_read_io_threads）的调优，它们对吞吐影响更直接
线程池真正起效的前提是：你的瓶颈确实在“连接建立/销毁开销”或“短查询密集排队”，而不是磁盘 IO、锁冲突或执行计划差——后者调再多次 thread_pool_min_threads 也没用。
