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）； 重启后仍快速涨满？优先排查代码或部署配置，而非一味扩容。
