mysql 8.0社区版默认不支持线程池，仅企业版或percona server等第三方版本可用；需先确认show plugins中thread_pool状态为active，再设置thread_handling=pool-of-threads并调优thread_pool_size等参数。
线程池在MySQL 8.0中是否可用
MySQL Community Edition 8.0 默认不支持线程池（thread_pool），该功能仅限企业版或部分第三方编译版本（如Percona Server、MariaDB）。直接执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 在官方社区版会报错 ERROR 1126 (HY000): Can't open shared library 'thread_pool.so'。确认方式是运行 SHOW PLUGINS;，若输出中无 thread_pool 行，说明不可用。
替代方案：用 thread_cache_size 缓解连接风暴
社区版无法启用线程池，但可通过合理配置连接复用机制降低开销：
-
max_connections设为业务峰值的 1.2–1.5 倍（例如预估 1200 并发，设为 1500），避免瞬间打满 -
thread_cache_size推荐设为max_connections * 0.1（如 1500 → 150），但上限建议 ≤ 32（过高反而增加管理开销） - 应用层必须启用连接池（如 HikariCP、Druid），控制实际到 MySQL 的活跃连接数，否则
thread_cache_size几乎无效 - 监控
Threads_created状态变量，若每秒持续 > 10，说明缓存不足或连接未复用
如果真有线程池（企业版/Percona），关键参数怎么设
启用前提：已安装插件且 thread_handling = 'pool-of-threads'。核心参数需按 CPU 资源和负载特征调整：
-
thread_pool_size：建议设为 CPU 物理核心数（非超线程数），16 核服务器设 16；超过 32 核可设为 24–32，避免调度过载 -
thread_pool_max_threads：默认 100000 过大，建议压测后设为max_connections * 1.2，防止突发请求耗尽工作线程 -
thread_pool_stall_limit：默认 500000 微秒（500ms），若业务含长事务，可调至 1000000（1s），避免误判“停滞” - 务必关闭
innodb_thread_concurrency（设为 0），否则线程池与 InnoDB 并发控制会冲突
容易被忽略的监控点和陷阱
线程池不是“开箱即用”的银弹，以下三点常被跳过却直接影响效果：
- 启用后
Threads_connected和Threads_running含义变化：前者是总连接数，后者是当前被分配到工作线程的活跃查询数，比值长期 > 0.8 说明线程组过载 -
thread_pool_oversubscribed持续增长，代表线程组内排队任务过多，需调大thread_pool_size或优化慢查询 - 日志中出现
Thread pool: thread group N is oversubscribed错误时，不是立刻加资源，先查SHOW PROCESSLIST是否有未提交事务或锁等待
线程池真正起效的前提，是上层应用连接行为可控、SQL 效率达标——否则只是把瓶颈从“创建线程”转移到“排队等线程”。
