thread_cache_size 设置需结合连接模式与监控指标：若 threads_created 每小时增长数百上千且 threads_cached 长期≤2，则过小；短连接场景建议设为 max_connections 的 1/8 至 1/4（如 32–64），长连接或有连接池时保持默认即可。
thread_cache_size 设置得当，能明显降低高并发下 Threads_created 持续上涨带来的 CPU 和内存开销。它不是越大越好，关键看实际连接模式和监控指标。
怎么看当前线程缓存是否够用？
直接查两个状态变量：Threads_created 和 Threads_cached。如果 Threads_created 在 1 小时内增长超过几百甚至上千，说明大量连接在反复创建线程；同时 Threads_cached 长期为 0 或极低（比如始终 ≤ 2），基本可判定 thread_cache_size 过小。
-
SHOW GLOBAL STATUS LIKE 'Threads_created';—— 累计创建数，重启后归零 -
SHOW GLOBAL STATUS LIKE 'Threads_cached';—— 当前缓存中空闲线程数 - 再对比
SHOW VARIABLES LIKE 'thread_cache_size';，确认配置值
短连接场景下怎么设 thread_cache_size？
Web 应用、脚本类调用、无连接池的客户端，属于典型短连接：连完即断，频繁新建。这类场景下线程复用率低，必须靠增大缓存兜住峰值。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 先观察峰值
Threads_created增速，例如每分钟新增 60 个线程，说明每秒约 1 个新连接 -
thread_cache_size建议设为max_connections的 1/8 到 1/4，但不超过 64（MySQL 5.7 默认上限） - 常见取值：32 或 48；若
max_connections=1000，可试设thread_cache_size=64 - 设完立刻生效：
SET GLOBAL thread_cache_size = 48;，但需同步写入my.cnf防重启丢失
长连接或用了连接池时要不要调大？
Java 应用配了 HikariCP、Druid，或 Node.js 用了 mysql2 的 connection pool，本质是复用连接，Threads_created 增长会非常缓慢。此时盲目调大 thread_cache_size 没意义，还可能浪费内存。
- 优先保持默认值（MySQL 5.7 默认是 16，部分发行版可能是 8 或 32）
- 只要
Threads_cached能稳定在 5–15 之间，且Threads_created每小时只增个位数，就不需调整 - 注意：连接池 idle timeout 设置过短（如
idleTimeout=30000），会导致连接被频繁回收，反而模拟出“伪短连接”，这时得调连接池参数，而不是硬抬thread_cache_size
改完怎么验证效果？
别只看配置写进去了，重点盯运行时指标变化。改完等 10–15 分钟，再比对前后 Threads_created 增速。
- 执行
FLUSH STATUS;清空统计（慎用，仅测试环境），或记录改前/改后 5 分钟的Threads_created差值 - 理想情况：相同业务压力下，
Threads_created增速下降 50% 以上，Threads_cached稳定在配置值的 60%–90% - 反常信号：改大后
Threads_cached仍长期为 0，说明连接根本没断开（可能是应用没 close，或 wait_timeout 太大），这时该查应用代码或wait_timeout设置
thread_cache_size 与你的连接生命周期、应用断连行为、以及 wait_timeout / interactive_timeout 的配合。光调这个参数，不看 Threads_created 实际走势，很容易白忙活。
