mysql社区版8.0默认不支持线程池，仅企业版或percona server等支持；启用前须通过show plugins确认thread_pool插件存在，否则配置无效。
线程池启用前必须确认版本和插件支持
MySQL 社区版 8.0 默认不带 thread_pool 插件，只有企业版或某些发行版（如 Percona Server、MariaDB）原生支持。直接执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 会报错 Plugin 'thread_pool' is not installed。先查清楚当前环境：SHOW PLUGINS; 看是否有 thread_pool 行；没有的话，别硬配 thread_handling = pool-of-threads，否则启动失败或被忽略。
thread_pool_size 设置不能只看 CPU 核数
很多人按“CPU 核数 = thread_pool_size”设，结果高并发下响应反而变慢。真实瓶颈常在 I/O 或锁竞争，不是纯 CPU。建议从 16 起步（8 核以上机器），再结合监控动态调：SHOW STATUS LIKE 'Threads_running'; 如果长期 > thread_pool_size，说明线程组不够用；如果 Threads_waited 持续增长，说明请求排队严重，需增大；但超过 32 后收益递减，还可能因队列调度开销抵消收益。
-
thread_pool_size建议值范围：12–24（常见 OLTP 场景） - 每组线程默认处理 4–8 个连接，不是 1:1 绑定
- 不要和
innodb_thread_concurrency同时设高值，二者冲突会加剧争抢
配合 thread_cache_size 防止连接抖动
即使启用了线程池，thread_cache_size 仍要设。它缓存的是“空闲线程对象”，避免频繁 malloc/free。若该值太小（比如 0 或 2），Threads_created 会上升，尤其在连接短频快的微服务场景。合理值是 max_connections 的 25%，但上限建议不超过 64：
- 设
thread_cache_size = 32后，观察Threads_created是否趋稳 - 如果
Threads_connected波动剧烈（比如 50 ↔ 300），说明应用层连接复用差，光调 MySQL 没用 -
open_files_limit必须 ≥max_connections × 3，否则线程池初始化阶段就卡住
线程池无法解决事务阻塞问题
线程池只是把“一个连接一个线程”换成“多个连接共享一组线程”，但它不区分查询类型。一个长事务（比如 UPDATE ... WHERE ... 执行 5 秒）会独占某个线程组，导致同组里其他简单 SELECT 一起卡住——这和没开线程池时的阻塞表现不同，但实际影响类似。真正缓解得靠：
- 业务侧拆分长事务，用更细粒度提交
- SQL 层加
MAX_EXECUTION_TIME=2000（MySQL 5.7+）防单条语句霸占资源 - 监控
INFORMATION_SCHEMA.PROCESSLIST中State为updating或Locked的连接持续时间
线程池是并发资源调度的“减压阀”，不是万能解药。容易被忽略的是：它对短平快查询提升明显，但对锁等待、磁盘 I/O 瓶颈、索引缺失导致的慢查询，完全无效。
