mysql线程池仅企业版支持，社区版无thread_pool插件；启用需先加载插件并设thread_handling=pool-of-threads；thread_pool_size为线程组数，需配合thread_pool_oversubscribe控制每组并发，否则参数无效。
MySQL线程池只在企业版中可用，社区版无论怎么配都不会生效——这是你调参无效的根源。
确认 thread_pool 插件是否真的可用
线程池不是配置开关就能开的功能，它依赖 thread_pool 插件，而该插件仅内置于 MySQL Enterprise Edition。MariaDB、Percona Server（默认构建）、所有社区版 MySQL 都不包含这个插件文件（thread_pool.so 或类似名称），执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 会直接报错：Plugin 'thread_pool' is not loaded。
验证方式只有这一条命令：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'thread_pool';
如果返回空行或状态为 DISABLED，说明当前环境根本不支持，别继续改 thread_pool_size 或 thread_pool_stall_limit —— 它们全被忽略。
- 社区版替代方案：用连接池中间件（如 ProxySQL、MaxScale）或应用层连接池（HikariCP、Druid）控制并发，再配合
thread_cache_size缓解线程创建压力 - 企业版部署前，先检查许可证是否激活，有些云厂商提供的“企业版”镜像实际未启用线程池模块
thread_handling = pool-of-threads 是硬性前提
即使插件已加载成功，MySQL 默认仍走传统 one-thread-per-connection 模式。thread_handling 必须显式设为 pool-of-threads，否则所有线程池参数（包括 thread_pool_size）全部失效。
常见错误现象：
-
INFORMATION_SCHEMA.THREAD_POOL_STATS表为空 -
SHOW PROCESSLIST中大量Sleep线程独占线程资源，而不是被统一调度 -
Threads_running和Threads_waited指标无变化，监控不到线程组行为
必须在 [mysqld] 段中写死这一行：
thread_handling = pool-of-threads
注意：thread_handling 是开关型参数，只接受两个值：one-thread-per-connection（默认）或 pool-of-threads（启用线程池），拼写错误或大小写不符都会导致加载失败。
thread_pool_size 和 thread_pool_oversubscribe 的协同逻辑
thread_pool_size 不是“工作线程总数”，而是线程组（thread group）数量；每个组内可动态派生多个工作线程，具体数量由 thread_pool_oversubscribe 控制。
典型误配：
- 把
thread_pool_size设成 64（以为能扛 64 并发），结果单组排队过长，短查询延迟飙升 - 把
thread_pool_oversubscribe设成 10，导致一个组里堆积大量任务，长事务饿死小查询
推荐取值组合（以 8 核物理 CPU 为例）：
-
thread_pool_size = 8（等于物理核心数，非超线程数） -
thread_pool_oversubscribe = 2（OLTP 场景下，单组最多处理 2~3 个活跃请求，避免阻塞扩散） -
thread_pool_max_threads = 300（全局上限，5000 连接下真正并发执行的 SQL 通常远低于此） -
thread_pool_stall_limit = 60ms（单位必须带ms，太小引发调度抖动，太大无法及时识别慢查询）
性能影响点：增大 thread_pool_size 会提升并行度，但超过 CPU 核心数后，线程组间锁争用上升；增大 thread_pool_oversubscribe 能提高吞吐，但牺牲响应一致性——这不是简单调大就好的参数。
thread_pool_idle_timeout 和监控落地建议
thread_pool_idle_timeout 控制空闲工作线程存活时间，默认 60 秒。高波动负载下可设为 30 或更低，加快释放内存，但要注意：频繁启停线程本身也有开销，不宜低于 15 秒。
真正关键的是监控是否生效，而非参数是否写对：
- 查
INFORMATION_SCHEMA.THREAD_POOL_STATS：看GROUP_ID分布是否均匀，有无长期为 0 的组（说明负载倾斜） - 盯
Threads_waited状态变量：持续上升意味着线程组调度不过来，需调低thread_pool_oversubscribe或优化慢查询 - 对比
Threads_running和Threads_connected：前者应稳定在几十量级，后者可上几千——这才是线程池起效的标志
最容易被忽略的一点：线程池不会加速单条慢 SQL，它只优化“大量连接+大量短查询”的场景；如果你的瓶颈是 SELECT * FROM huge_table ORDER BY unindexed_col，调 thread_pool_size 没有任何意义。
