能缓解但不能直接救急；它是防止线程频繁创建销毁导致雪崩的关键缓冲层，通过复用空闲线程降低cpu和内存压力，但前提是max_connections未打满且os资源充足。
连接数突增时，thread_cache_size 能不能救急？
不能直接“救急”，但它是防止雪崩的关键缓冲层。当应用侧突发大量短连接（比如秒杀、定时任务集中触发），MySQL 每次都新建线程，Threads_created 会飙升，CPU 和内存压力陡增，严重时触发 OOM 或拒绝新连接。此时 thread_cache_size 的作用是：让断开的线程不立刻销毁，等下个连接来时直接复用——省掉线程创建/销毁开销，把资源消耗压下来。
但它不是连接池，也不控制连接总数；它只管“空闲线程怎么留”。如果 max_connections 已被打满，调大 thread_cache_size 毫无意义。
怎么判断当前 thread_cache_size 是否过小？
看两个状态值的比值：Threads_created / Connections。这个比值 > 0.01（即每 100 个连接就新建 1 个线程），说明缓存命中率太低，线程反复创建销毁。
SHOW GLOBAL STATUS LIKE 'Threads_created';SHOW GLOBAL STATUS LIKE 'Connections';
再补查一眼缓存中实际有多少空闲线程：SHOW GLOBAL STATUS LIKE 'Threads_cached';。如果长期 Threads_cached 稳定在 0 或个位数，而 thread_cache_size 设的是 16，那基本就是配置没生效或负载远超预期。
thread_cache_size 设多大才合适？
别套公式，看真实负载。生产环境常见误区是照搬“max_connections 的 10%–20%”这种建议，结果在 2000 连接的实例上硬配 200，每个线程吃掉 512KB 内存，光缓存线程就占掉 100MB+，得不偿失。
更务实的做法：
- 先观察峰值
Threads_connected（SHOW STATUS LIKE 'Threads_connected';），取其 1.2–1.5 倍作为起点，比如峰值 300，就从 40 开始试 - 短连接为主（HTTP API 类）：设 8–32，重点压
Threads_created下降 - 长连接为主（常驻服务 + 连接池）：4–16 足够，甚至可设为 0（MySQL 5.7+ 支持动态关闭缓存）
- 上线后盯紧
Threads_cached，理想状态是它能稳定在设置值的 60%–90%，而不是长期打满或长期为 0
为什么调了 thread_cache_size 还是扛不住突增？
因为真正卡脖子的往往不在这里。容易被忽略的三个硬约束：
-
max_connections太小：比如只设 200，但应用侧 HikariCPmaximumPoolSize=50× 4 台机器 = 200，没留余量，一有重连就全堵死 - OS 层限制没跟上：
ulimit -n小于max_connections + 保留余量，MySQL 连接文件描述符不够，直接报Can't create thread (errno: 11) - 连接不释放：
wait_timeout还是默认 8 小时，大量 sleep 连接堆积，Threads_connected虚高，挤占真正需要的连接位
所以调 thread_cache_size 前，务必先确认 max_connections 是否合理、OS 限制是否放开、应用连接池是否设置了 idleTimeout 和 maxLifetime，否则单点优化只是给快崩溃的系统多塞一张纸巾。
