MySQL短连接吃CPU和内存因频繁创建销毁连接，触发为每个连接分配独立线程及资源，导致上下文切换高、Threads_created飙升；需手动设置thread_cache_size（如8）启用线程缓存。
MySQL短连接为什么吃CPU和内存
短连接频繁创建销毁，会直接触发MySQL为每个连接分配独立线程（Linux下是pthread），包括栈空间、网络缓冲区、权限结构体等。这不仅拉高CPU上下文切换开销，还会让Threads_created指标飙升——你查SHOW GLOBAL STATUS LIKE 'Threads_created';，如果每秒增长超过5–10，基本就是短连接在“打桩”。
ThreadCache不是自动开启的，必须手动配
MySQL默认thread_cache_size是0，意味着完全不缓存空闲线程。哪怕你有1000 QPS的短连接，也会1000次调用pthread_create。要启用缓存，必须显式设置：
SET GLOBAL thread_cache_size = 8;
注意这不是动态生效的“开关”，而是运行时生效的配置项。常见合理值范围是4–16，取决于并发连接峰值和连接复用频率：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 若
Threads_created每秒新增 thread_cache_size设为4足够 - 若应用使用连接池但仍有突发流量，建议先设为8，再观察
Threads_cached是否稳定在3–6之间 - 超过16意义不大——缓存太多空闲线程反而占内存，且MySQL内部管理开销会上升
ThreadCache只对“断开但未销毁”的连接起作用
关键点：缓存生效的前提是客户端主动发送QUIT或TCP FIN后，MySQL把该线程放入缓存队列，而不是立刻pthread_exit。这意味着：
- 客户端必须正常关闭连接（比如Python里
conn.close()，Java里connection.close()），不能靠超时中断或进程崩溃 - 如果MySQL配置了
wait_timeout或interactive_timeout太小（如30秒），连接容易在缓存前就被强制kill，导致缓存命中率低 -
Threads_cached值长期为0，大概率是客户端没正确close，或者网络中间件（如HAProxy）启用了TCP keepalive但没透传FIN
别只盯着thread_cache_size，配合检查max_connections和Aborted_connects
盲目调大thread_cache_size可能掩盖更严重的问题：
- 如果
Aborted_connects持续上升，说明大量连接连认证都没过（密码错、host拒绝、包损坏），此时加缓存毫无意义 -
max_connections设得太低会导致新连接被拒绝，而thread_cache_size再大也救不了——缓存的是“可用线程”，不是“可接受连接数” - 真正压测时发现响应延迟卡在200ms左右波动？大概率是
thread_cache_size不够+wait_timeout太短，线程刚缓存几秒就被清掉，又得重建
线程缓存只是短连接优化的其中一环，它不解决连接设计缺陷，也不替代连接池。真正稳定的系统，往往在应用层用连接池控住并发，再用thread_cache_size兜底应对毛刺流量。
