thread_cache_size宜设为CPU核数的1～2倍，短事务调至8～12，长阻塞事务可增至25～40，并需匹配连接池配置、关闭autoReconnect、启用validationQuery验证，确保Threads_cached稳定在设定值60%～90%且Threads_created增速缓慢。
thread_cache_size 设置多少才不算浪费又不卡顿
MySQL 的 thread_cache_size 控制空闲线程缓存数量，本质是复用刚断开连接的线程，避免频繁创建/销毁线程带来的开销。它不是“并发连接数上限”，也不影响新连接能否建立——那是 max_connections 管的事。
常见误判：看到监控里 Threads_created 持续上升，就盲目调大 thread_cache_size。其实得先看增长速率和业务节奏：
- 如果每秒新增线程 thread_cache_size = 2~4 足够
- 短连接高频场景（如 PHP-FPM 默认配置、无连接池的 Java 应用），
thread_cache_size = 8~16较稳妥 - 超过 16 后收益急剧下降；设到 32 以上几乎没额外好处，反而让内存驻留更多空闲线程
- 可通过
SHOW STATUS LIKE 'Threads_created'对比重启后累计值与运行时长，算出平均创建速率
connection pool 大小该以什么为依据
应用层连接池（如 HikariCP、Druid、mysql-connector-python 的 pool_size）和 MySQL 的 thread_cache_size 是两层独立机制，但协同影响整体吞吐。池大小不合理，再好的 thread_cache_size 也救不了。
关键原则：连接池不是越大越好，而是要匹配数据库真实处理能力 + 网络往返延迟 + 事务平均耗时：
小兵小兵建站CMS V1.0(内容管理系统)，基于OneThink开源框架，和超过300家以上网站建设客户进行了深度的合作与需求沟通，经过了一年时间的研发，打造了国内最简洁好用、易于操作的网站管理后台。小兵建站CMS，国内最简单易用的网站管理系统！永久免费开源！小兵建站CMS服务器配置要求：安装环境：PHP 版本 5.3以上 ； mysql: 5.0以上 IIS： 7.0 以上 安装
- 默认 10～20 是安全起点；生产环境建议从 15 开始压测，逐步增加到响应时间明显上升或
Threads_running长期 > CPU 核数 × 2 为止 - 若应用有大量短事务（如单条 INSERT/SELECT），可适当收紧池大小（如 8～12），减少线程上下文切换
- 若事务常含远程调用或文件 IO，线程会长时间阻塞在非 DB 操作上，此时池可以稍大（如 25～40），但必须配合超时设置（
connectionTimeout、idleTimeout）防连接滞留 - 务必关闭连接池的“自动提交”以外的隐式行为（如某些驱动默认开启
autoReconnect），否则会干扰thread_cache_size的复用逻辑
thread_cache_size 和 connection pool 冲突的典型表现
当两者配置失配时，不会报错，但会出现隐蔽的性能毛刺或资源浪费：
-
thread_cache_size过小 + 连接池过大 →Threads_created暴涨，MySQL error log 出现 “Too many connections” 前就有大量线程创建销毁日志 -
thread_cache_size过大 + 连接池过小 → 空闲线程长期驻留，Threads_cached接近上限，但Threads_connected始终很低，属于纯内存浪费 - 连接池启用了“testOnBorrow”但没配
validationQuery→ 每次取连接都触发一次COM_PING，MySQL 视为新请求，绕过 thread cache，等效于thread_cache_size = 0 - 应用使用长连接但未正确 close（靠 GC 回收），连接池实际连接数虚高，MySQL 端
Threads_connected居高不下，thread_cache_size完全失效
如何验证当前配置是否合理
不能只看某一个指标，要组合观测运行时状态：
- 执行
SHOW STATUS LIKE 'Threads%'，重点关注三个值：Threads_connected（当前连接数）、Threads_running（活跃线程数）、Threads_cached（缓存中的空闲线程数）。理想状态是Threads_cached稳定在设定值的 60%～90%，且Threads_created增速缓慢（例如 1 小时增长 - 用
mysqladmin extended -r -i 1 | grep Threads实时观察变化趋势，避开业务低峰期做基线对比 - 连接池侧需打开详细日志（如 HikariCP 的
debug级别），确认连接获取/归还频率、超时丢弃数、是否发生连接泄漏 - 特别注意慢查询日志中是否出现大量 “Opening tables” 或 “Creating sort index” 等状态，这类操作本身不依赖线程缓存，但会放大线程争用——此时调大
thread_cache_size无效，得优化 SQL 或索引
最易被忽略的一点：MySQL 8.0+ 默认启用 skip_name_resolve，但如果 DNS 不稳定，连接建立阶段仍可能卡在 hostname 解析，导致连接池误判为 DB 响应慢而扩容，最终把 thread_cache_size 和池大小都推向错误方向。
