thread_cache_size在MySQL 8.0中仍关键，因每个新连接仍需独立线程，频繁创建/销毁会触发系统调用、消耗CPU，缓存复用可跳过开销；合理值为16–256，需据Threads_created增速和Threads_cached命中率动态调整。
MySQL 8.0 的 thread_cache_size 不是“越大越好”，设得过高反而浪费内存、降低线程调度效率；合理值通常在 16–256 之间，需结合 max_connections 和实际 Threads_created 增速来定。
为什么 thread_cache_size 在 MySQL 8.0 里依然关键
即使 InnoDB 已全面接管事务和锁管理，每个新连接仍需一个独立线程（mysqld 线程模型未变）。频繁创建/销毁线程会触发系统调用、消耗 CPU，并可能引发 pthread_create 失败或延迟。缓存复用线程能直接跳过这部分开销。但注意：MySQL 8.0 默认已关闭查询缓存（query_cache_type 无效），所以线程缓存是连接层为数不多可低成本优化的点之一。
常见错误现象：
- 监控发现
Threads_created每秒持续增长 > 5–10，说明缓存严重不足 - 应用端偶发连接建立慢（非超时），
SHOW PROCESSLIST中大量Connecting状态 - 配置了
thread_cache_size = 512后内存占用明显上升，但Threads_cached长期低于 50，说明冗余
怎么设一个靠谱的 thread_cache_size 值
别套公式硬算，直接看实时指标反推：
- 先查当前速率：
SHOW GLOBAL STATUS LIKE 'Threads_created';，间隔 60 秒再查一次，差值就是这一分钟新建线程数 - 如果每分钟新增 > 600（即每秒 > 10），
thread_cache_size至少设为 32；若 > 1200（每秒 > 20），可试 64–128 - 观察
Threads_cached：稳定运行 1 小时后，它应长期维持在设定值的 60%–90%。长期 Threads_created 仍在涨，说明还不够 - 生产环境建议起始值：
thread_cache_size = 32（中小并发）、64（500+ 连接）、128（1000+ 连接且 CPU 核心 ≥ 16）
示例（动态生效）：SET GLOBAL thread_cache_size = 64;。注意：该值不持久，必须写入 my.cnf 的 [mysqld] 段落才能重启保留。
容易被忽略的配套动作
thread_cache_size 单独调高没用，必须配合以下三点：
- 确认
max_connections已按需上调（比如从默认 151 改到 1000），否则线程根本没机会进缓存队列 - 检查
wait_timeout和interactive_timeout是否仍为 28800（8 小时）——这会导致连接空闲太久才释放，缓存线程长期“占位不干活”，建议压到600（10 分钟） - 应用层必须用连接池（如 HikariCP 的
maximumPoolSize），否则每次请求都新建连接，线程缓存形同虚设
一个典型陷阱：thread_cache_size = 256 + max_connections = 151，结果 Threads_cached 永远是 0 —— 因为根本没那么多并发连接来触发缓存逻辑。
最后提醒一句
线程缓存只缓解“连接建立”阶段的开销，它不解决慢查询、锁等待或磁盘 I/O 瓶颈。如果你看到 Threads_created 稳定但 Threads_running 长期 > 50，问题大概率在 SQL 或索引上，这时候调 thread_cache_size 没意义。
