mysql中连接数超出限制的排查与解决方法

mysql连接数超限表现为“too many connections”，需先查max_connections、threads_connected及processlist识别sleep/query/locked等异常连接，再kill或调参优化。

查看当前连接数和最大连接限制

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-timeout wait_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 又等太久才断」——两边超时没对齐，是最容易被忽略的协同盲区。