MySQL社区版8.0不支持thread_pool插件，仅企业版、Percona Server或MariaDB提供；应调优thread_cache_size缓解短连接开销，并关闭DNS解析、合理设置超时参数。
社区版 MySQL 8.0 根本不支持 thread_pool 插件
直接执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 会报错 Unknown plugin 'thread_pool'——这不是配置问题，是版本限制。MySQL 社区版（包括 8.0 和 5.7）原生不含线程池功能，只有 MySQL Enterprise Edition、Percona Server 或 MariaDB 才提供 thread_pool_size 等参数。强行在社区版里加配置项（如 thread_handling = pool-of-threads）会被忽略，SHOW VARIABLES LIKE 'thread_handling' 仍显示 one-thread-per-connection。
短连接场景下真正该调的不是“线程池”，而是 thread_cache_size
社区版唯一能缓解短连接线程开销的机制，是复用空闲线程而非创建新线程。thread_cache_size 就是干这个的。它不是“缓存连接”，而是缓存刚销毁的线程上下文，供下一个连接快速复用。
- 查当前压力：
SHOW STATUS LIKE 'Threads_created'，如果每秒增长 > 1，说明缓存不够 - 设值公式：取
ceil(max_connections / 16)，但上限建议 ≤ 32（过高反而增加管理开销） - 配合
max_connections = 800，thread_cache_size = 16是常见稳态组合 - 注意：
thread_cache_size对长连接无效，只对频繁建连/断连的短连接起作用
比调参更关键的是关掉 DNS 解析和缩紧超时
很多团队花时间调 thread_cache_size，却忽略两个更致命的瓶颈：DNS 反向解析阻塞连接建立，以及空闲连接长期不释放占满限额。
- 启动 MySQL 必须加
--skip-name-resolve，否则每个连接都可能卡在 hostname 解析上（尤其容器环境） -
wait_timeout和interactive_timeout必须统一设为30（单位秒），不能留默认的 28800 - 应用层连接池的
idleTimeout要比wait_timeout大一点（例如 60 秒），但绝不能小，否则连接归还时已被 MySQL 主动断开 - 验证是否生效：
SHOW PROCESSLIST中不应有大量Sleep状态且Time> 30 的连接
如果你真需要线程池，得换数据库或加中间件
硬要在线程粒度做复用（即一个线程服务多个连接的不同 SQL），社区版 MySQL 没得选。替代路径只有两条：
- 换 Percona Server 或 MariaDB，并确认已加载插件：
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'，再设thread_pool_size = 16（接近 CPU 逻辑核数） - 不换 DB，加 ProxySQL 或 MySQL Router 作为连接池代理，它在客户端和服务端之间做连接复用，把 N 个客户端连接映射到 M 个后端连接（M ≪ N），效果接近线程池
- 注意：ProxySQL 的
mysql-pooling必须开启，且后端max_connections要按实际并发量重估，别照搬前端连接池大小
线程池不是银弹。即使在 Percona 里启用，thread_pool_stall_limit 设错也会导致查询被误判 stall，引发频繁迁移和上下文切换——这比不用还糟。
