mysql 8.4 lts 社区版不支持 thread_pool 插件，仅企业版可用；确认方式为执行 select version(), @@version_comment 和 show plugins like 'thread_pool'，输出含 commercial/enterprise 且插件状态为 active 才支持。
MySQL 8.4 LTS 社区版不支持 thread_pool 插件，无法通过任何配置启用它。 这不是操作问题，而是版本和许可限制——thread_pool 是 MySQL Enterprise Edition（企业版）专属功能，社区版内核缺少对应调度 hook，INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 必然报错 Plugin 'thread_pool' is not supported。
怎么确认自己用的是不是企业版
别靠安装包名称或官网下载页判断，直接查运行时信息：
-
SELECT VERSION(), @@version_comment;—— 输出里必须含Commercial或Enterprise才可能支持 -
SHOW PLUGINS LIKE 'thread_pool';—— 社区版返回空结果，企业版才显示ACTIVE -
ls -l $MYSQL_HOME/lib/plugin/thread_pool*—— 社区版该路径下通常无文件，企业版才有thread_pool.so
社区版替代 thread_pool 的真实有效手段
线程池解决的是“连接多、事务短、线程创建销毁开销大”场景下的 CPU 上下文切换瓶颈。社区版没它，但可通过组合配置逼近类似效果：
-
thread_cache_size设为 16–32：复用空闲线程，避免频繁pthread_create，对中等并发（几百连接）效果明显 -
max_connections按内存估算：每连接约占用 2–3MB，32GB 内存服务器设到 1000 左右较安全，再高需压测 -
wait_timeout和interactive_timeout降到 60–180 秒：快速回收空闲连接，腾出max_connections名额 - 应用层必须用连接池（如
HikariCP），连接数上限建议设为 CPU 逻辑核数 × 2～4，避免连接泄漏
为什么调了 thread_pool_size 还是报 Too many connections
这是最常被误解的点：thread_pool 不改变 max_connections 限制，也不增加允许接入的连接数。它只优化“已建立连接”的服务效率。
- 报错
Too many connections说明客户端连接数已 ≥max_connections，此时无论线程池是否启用，新 TCP 握手都会被拒绝 - 真正要扩容，并不是调
thread_pool_size，而是：评估内存后调大max_connections+ 缩短wait_timeout+ 应用层连接复用 -
thread_pool_waited持续增长才表示线程池资源不足；而Threads_created高、Threads_cached低，才是thread_cache_size不够的信号
线程池不是银弹，社区版用户更应聚焦在连接生命周期管理、InnoDB 缓冲池命中率、索引覆盖和事务粒度上——这些地方的收益远高于纠结一个不可用的插件。
