MySQL 8.4 LTS社区版不支持线程池功能，因许可与内核限制，INSTALL PLUGIN会报错，SHOW PLUGINS无结果，相关系统变量不存在，可用thread_cache_size等调优替代。
MySQL 8.4 LTS 社区版不支持线程池（thread_pool）功能，无论怎么配置或安装插件都会失败——这不是操作错误，而是许可和内核限制。
确认 thread_pool 是否可用，别靠安装包名判断
社区版里执行 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*—— 社区版该路径下通常无任何文件
为什么 SET PERSIST thread_pool_size 没反应
这个参数根本不存在于社区版的系统变量列表中。SHOW VARIABLES LIKE '%thread_pool%' 返回空，说明内核压根没加载相关逻辑。所有试图通过配置项（如 thread_pool_size、thread_pool_stall_limit）启用它的操作，都会被忽略或直接报错 Unknown system variable。
常见误解是把 thread_cache_size 当成线程池：它只是复用空闲连接线程，不涉及任务调度与 worker 分片，和企业版的 thread_pool 完全不是一回事。
社区版替代方案：聚焦连接复用与资源回收
线程池解决的是“高并发短事务 + 频繁线程创建销毁”场景下的 CPU 上下文切换瓶颈。社区版虽无原生线程池，但可通过组合调优逼近类似效果：
-
thread_cache_size设为 16–32：避免每次新连接都调用pthread_create，对几百级并发有效 -
max_connections按内存估算：每连接约占 2–3MB，32GB 内存服务器设到 1000 左右较安全 -
wait_timeout和interactive_timeout降到 60–180 秒：防止空闲连接长期占坑 - 应用层必须用连接池（如 HikariCP），连接数上限建议 ≤ CPU 逻辑核数 × 4，且务必开启
connection-test-query防泄漏
并行查询 ≠ 线程池，别混淆这两个机制
MySQL 8.4 的 parallel_query 是独立功能，用于加速单条大查询（如 COUNT(*)、范围扫描），它依赖 innodb_parallel_read_threads，和连接调度无关。你可以在社区版放心启用它：
SET PERSIST innodb_parallel_read_threads = 16;SET SESSION parallel_threads_limit = 8;
然后用 EXPLAIN ANALYZE SELECT COUNT(*) FROM big_table; 查看 Extra 字段是否出现 Using parallel scan (8 workers)。这是社区版用户当前最值得投入的并发优化点。
真正容易被忽略的是：线程池在企业版中也只优化“已建立连接”的处理效率，它不会提升 max_connections 上限，也不会缓解慢查询或锁等待。社区版用户更应盯紧 Threads_created、Aborted_connects、Innodb_buffer_pool_hit_ratio 这些指标，而不是徒劳地找一个根本不存在的开关。
