MySQL连接数暴增主因是连接未及时释放或无效连接过多，需重点排查空闲连接、慢查询、长事务及应用层连接池配置，并通过调整wait_timeout、限制用户连接数等参数优化。
MySQL连接数暴增，核心是“连接没及时释放”或“不该开的连接开了太多”。重点不是看总数，而是看谁在连、连了多久、干了什么、有没有卡住。
查当前连接数和活跃度
先确认是否真爆了：
-
Threads_connected：当前所有连接数，用
SHOW GLOBAL STATUS LIKE 'Threads_connected';查； -
Threads_running：正在执行查询的连接数，用
SHOW GLOBAL STATUS LIKE 'Threads_running';查； - 如果 Threads_connected 远大于 Threads_running（比如 300 vs 5），说明大量连接处于空闲（Sleep）状态，大概率是应用没关连接；
- 同时对比
SHOW VARIABLES LIKE 'max_connections';，确认是否接近上限（如 300/300）。
看谁连的、连了多久、在干什么
执行 SHOW PROCESSLIST; 或更全的 SHOW FULL PROCESSLIST;，重点关注四列：
- User + Host：哪个应用用户、从哪台机器连进来？可定位异常来源（如陌生IP、测试账号）；
-
Command：多数是
Sleep（空闲）、Query（正在执行）、Connect（刚连上）； -
Time：单位秒。Sleep 超过
wait_timeout（默认 28800 秒=8小时）本该断开，若出现几百上千秒的 Sleep，说明连接泄漏； -
State：如
Sending data、Locked、Updating等，配合慢查询分析是否被阻塞。
查慢查询和长事务
慢查询或未提交事务会把连接长期占住：
- 启用慢日志（如未开）：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2;； - 查最近慢 SQL：
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;（需开启日志表）； - 查长时间未提交事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;； - 结合
PROCESSLIST中 Time 长且 Command 是Query、State 是updating或locked的线程，重点优化对应 SQL 或业务逻辑。
检应用层连接管理
绝大多数暴增源于应用侧问题：
- 检查连接池配置（如 HikariCP、Druid）：最大连接数是否远超 MySQL 的
max_connections？多个服务共用库时是否叠加超限？ - 确认是否用了 try-with-resources（Java）、using（.NET）或 finally 显式 close()，尤其在异常分支里；
- 是否存在“一个请求开多个连接但只关一个”的写法；
- 监控连接池指标：活跃连接数、等待获取连接的线程数、连接平均生命周期——若活跃数持续高位不降，基本可判定泄漏。
调关键参数防堆积
临时缓解+长期加固：
- 降低空闲连接存活时间：
SET GLOBAL wait_timeout = 600;（10分钟），interactive_timeout同步调整； - 限制单用户连接上限（防某应用失控）：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 50;； - 谨慎调高
max_connections，需同步评估内存（每个连接约占用 2–3MB）； - 重启后仍快速涨满？优先排查代码或部署配置，而非一味扩容。
