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也没用。
