查看当前连接数和最大连接限制
MySQL 连接数超限最直接的表现是客户端报错
Too many connections。先确认实际连接数和配置上限，避免误判： 执行
SHOW VARIABLES LIKE 'max_connections';查看允许的最大并发连接数（默认通常为 151） 执行
SHOW STATUS LIKE 'Threads_connected';获取当前活跃连接数 执行
SHOW PROCESSLIST;或
SELECT * FROM information_schema.PROCESSLIST;查看具体连接来源、状态、运行时长
注意：普通用户可能无权查
information_schema.PROCESSLIST，需用有
PROCESS权限的账号（如 root）。
识别长连接、空闲连接和异常连接
大量
Sleep状态连接常是应用未正确关闭连接导致的；而长时间
Query或
Locked状态则可能卡在慢查询或锁等待上。
Sleep状态且
Time值很大（比如 > 300 秒）：大概率是应用端连接池未回收、或设置了过长的
wait_timeout/
interactive_timeout
Query状态持续数分钟以上：用
SHOW FULL PROCESSLIST;看 SQL 内容，结合
EXPLAIN分析是否缺少索引或存在全表扫描
Locked或
Waiting for table metadata lock：说明被 DDL（如
ALTER TABLE）阻塞，需检查是否有长事务或未提交事务
临时释放连接与调整配置
紧急情况下需快速释放资源，再考虑长期优化：
手动 Kill 异常连接：KILL <code>id;（
id来自
SHOW PROCESSLIST输出），慎杀
system user或主从复制线程 临时调高上限（仅限应急）：
SET GLOBAL max_connections = 500;，但该值不能超过
max_connections的编译上限，且重启后失效 缩短空闲连接超时：
SET GLOBAL wait_timeout = 60;和
SET GLOBAL interactive_timeout = 60;，让闲置连接更快释放
这些
SET GLOBAL操作需 SUPER 权限，且不建议设得过低（如
应用层连接池与 MySQL 配置协同优化
单纯调大
max_connections是治标，连接泄漏或低效使用才是根源。关键要对齐应用连接池参数与 MySQL 超时设置： 若用 HikariCP，确保
connection-timeoutwait_timeout，且
idle-timeout和
max-lifetime合理（例如分别设为 300000 和 1800000） 若用 Druid，检查
minIdle是否过高、
removeAbandonedOnBorrow是否启用，避免连接堆积 MySQL 配置文件中应持久化设置：
max_connections = 300 wait_timeout = 300 interactive_timeout = 300，并重启 mysqld 生效 务必监控连接数趋势（如通过 Prometheus + mysqld_exporter），而不是等报警才介入
很多问题其实出在「应用没 close()，MySQL 又等太久才断」——两边超时没对齐，是最容易被忽略的协同盲区。
