MySQL连接数突增时，应优先监控Threads_running而非max_connections；启用线程池需谨慎配置thread_pool_size和stall_limit；应用层限流、SQL超时、批量操作及连接池参数协同优化才是根本。
MySQL连接数突增时，max_connections不是第一道防线
直接调高 max_connections 只会掩盖问题，还可能引发内存耗尽或线程切换开销激增。真正要盯的是“活跃连接中真正执行 SQL 的线程数”，而不是总连接数——很多连接是空闲的、长连接保活的、或应用未正确关闭的。
实操建议：
- 用
SHOW PROCESSLIST或查询information_schema.PROCESSLIST，重点关注Command为Query、Execute，且Time持续 >5s 的线程 - 检查
Threads_running（当前正在执行语句的线程数），它比Threads_connected更反映真实压力；持续高于 30–50 就需干预 - 确认应用层是否用了连接池（如 HikariCP、Druid），并设置了合理的
maxActive/maximumPoolSize和maxLifetime
MySQL 8.0+ 线程池插件（thread_pool）启用后反而更慢？
线程池插件不是“开箱即用”的银弹。它默认只对 CONNECTION 层做调度，不感知 SQL 执行耗时；若大量慢查询堆积在线程队列里，新请求仍会排队等待，响应时间不降反升。
关键配置与避坑点：
- 必须显式安装：
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so';（Linux）或'thread_pool.dll'（Windows） -
thread_pool_size建议设为 CPU 核心数 × 2（非越大越好），超配会导致上下文切换频繁；SSD 环境下可略保守（如 8 核设为 12） -
thread_pool_stall_limit控制单任务最长允许运行毫秒数（默认 600），设太小会误杀正常复杂查询，设太大则无法及时释放卡死线程 - 禁用
skip_thread_pool，并确保thread_handling = 'pool-of-threads'
应用侧执行线程调度比数据库端更重要
数据库线程池解决的是“OS 级线程复用”，但业务瓶颈往往在应用发来的请求节奏——比如定时任务批量拉取、前端重试风暴、或某个接口未加熔断导致雪崩式打穿连接池。
实操抓手：
- 在应用网关或服务入口加限流：Spring Cloud Gateway 用
redis-rate-limiter，或用 Sentinel 控制 QPS + 并发线程数双维度 - 数据库操作必须带超时：JDBC URL 加
connectTimeout=3000&socketTimeout=10000；MyBatis 的timeout属性不能留空 - 避免“查完再循环更新”类写法——这类逻辑极易把 N 次 DB 调用压成 N 个并发连接；改用批量语句（
INSERT ... ON DUPLICATE KEY UPDATE）或临时表预处理
wait_timeout 和 interactive_timeout 设太小会引发连接闪断
这两个参数控制空闲连接自动断开时间，看似能“快速回收连接”，但若设为 30–60 秒，而应用连接池的 idleTimeout 是 5 分钟，就会出现连接池认为连接可用、MySQL 却已悄悄关闭的错配，表现为偶发的 MySQLNonTransientConnectionException: No operations allowed after connection closed。
稳妥做法：
-
wait_timeout≥ 应用连接池的idleTimeout（例如 HikariCP 的idleTimeout是 300000ms，则 MySQL 至少设 300） - 连接池开启
connection-test-query（如SELECT 1）或使用validation-timeout，避免复用已失效连接 - 生产环境慎用
autoReconnect=true（JDBC 参数），它无法修复事务上下文丢失问题，且已被 MySQL 官方标记为废弃
真正难处理的从来不是连接数峰值本身，而是连接背后那个没被监控到的慢查询、那个没设超时的 HTTP 调用、或者那个每分钟跑一次却越积越厚的定时任务。线程池和参数调优只是止血，根因还在代码和架构里。
