MySQL 8.0+ 社区版不支持thread_pool插件，仅企业版可用；启用需配置plugin-load-add并设thread_pool_size≈CPU逻辑核数×2，且不缓解Too many connections问题。
MySQL 8.0+ 怎么启用 thread_pool 插件
MySQL 官方 thread_pool 插件只在 MySQL Enterprise Edition（企业版）中提供，社区版（Community Edition）默认不包含，也**无法通过 INSTALL PLUGIN 启用**。强行执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 会报错 Plugin 'thread_pool' is not supported。
常见误操作是去网上搜编译参数或第三方 patch，但实际生产环境应避免：企业版 license 是硬性前提，且插件依赖特定线程调度机制，社区版内核缺少对应 hook。
- 确认版本和 edition：
SELECT VERSION(), @@version_comment;—— 输出含Commercial或Enterprise才可能支持 - 检查插件目录是否存在：
ls -l $MYSQL_HOME/lib/plugin/thread_pool*，社区版通常无此文件 - 企业版启用方式：
mysqld --plugin-load-add=thread_pool.so --thread_pool_size=16，需写入配置文件并重启
thread_pool_size 设多少才合理
这个参数不是越大越好，它控制的是“工作线程组数”，每组内部复用线程处理多个连接请求；设太高反而引发锁竞争和上下文切换开销。
典型场景下，thread_pool_size 建议值 ≈ CPU 核心数 × 2（超线程开启时按逻辑核算），上限一般不超过 64。例如 16 核 32 线程服务器，从 16 或 24 开始压测，观察 SHOW STATUS LIKE 'Thread_pool%' 中的 Thread_pool_idle_threads 和 Thread_pool_waited 变化。
-
Thread_pool_waited > 0持续增长 → 当前 size 不足，需适度上调 -
Thread_pool_idle_threads长期接近thread_pool_size→ 过度配置，浪费资源 - OLTP 场景下，单次查询极短（毫秒级），
thread_pool_stall_limit（默认 60ms）容易误触发线程新建，可调低到 10–20ms 避免抖动
为什么开了 thread_pool 还是出现 Too many connections
thread_pool 解决的是线程创建/销毁开销和 CPU 调度效率问题，**不改变 max_connections 限制**。连接数超限仍会直接拒绝新连接，报错 Too many connections。
它只是让已建立的连接更高效地被服务，而不是允许更多连接进来。真正要扩容并发承载能力，必须同步调整：
-
max_connections：根据内存和业务连接模型估算，每连接约消耗 256KB–1MB 内存 -
wait_timeout/interactive_timeout：缩短空闲连接生命周期，加速连接回收 - 应用层务必使用连接池（如 HikariCP、Druid），避免每次请求都新建连接
否则即使 thread_pool 工作良好，连接池未配置或泄漏，也会迅速打满 max_connections。
thread_pool 和 connection_control 插件能共存吗
可以共存，但要注意加载顺序和冲突点。两者都是服务端插件，connection_control（用于登录失败延迟/锁定）作用在认证阶段，thread_pool 作用在连接建立后的查询执行阶段，逻辑上不重叠。
不过若 connection_control_failed_connections_threshold 设置过严，大量连接卡在认证环节，会导致 thread_pool 内部等待队列积压，表现为 Thread_pool_queued 上升、响应延迟升高，看起来像 thread_pool 生效了但性能没提升。
- 验证是否受干扰：
SHOW STATUS LIKE 'Connection_control%';查看失败计数 - 压测时关闭
connection_control对比基线，排除误判 - 二者都启用时，建议在 my.cnf 中按依赖顺序加载：
plugin_load_add = connection_control.so;thread_pool.so
thread_pool 的真实价值只在连接密集、查询轻量、CPU 成瓶颈的场景里体现；如果慢查询多、磁盘 I/O 高或者网络延迟大，调它没用——得先解决 SQL 和索引问题。
