故障现象描述
近期，部分企业内部的基于MySQL的应用系统（如OA、ERP或自定义业务平台）出现间歇性无法访问的情况。查看后端日志时，开发人员反馈报错信息为：java.sql.SQLException: Too many connections 或 ERROR 1040 (HY000): Too many connections。此时，应用程序虽然启动正常，但在高并发访问或特定业务高峰期，数据库服务表现为响应极慢或直接拒绝新连接请求。
故障根因分析
MySQL服务器在处理客户端连接时，需要分配特定的系统资源（如线程栈、缓冲区等）。为了防止单用户耗尽所有服务器资源，MySQL引入了最大连接数限制，即全局变量 max_connections。当同时活跃的连接数（包括空闲和正在执行的查询）达到该阈值时，新的连接请求将被直接拒绝。
导致连接数耗尽的常见原因通常分为以下三类：
- 连接泄露（Connection Leak）： 应用程序代码中存在缺陷，获取了数据库连接但未正确关闭，导致空闲连接不断累积。
- 长事务或慢查询： 某些复杂的业务逻辑或未及时优化的SQL语句执行时间过长，长时间占用数据库连接资源。
- 连接池配置不当： 应用服务器的数据库连接池（如HikariCP、Druid）最大连接数设置过大，超过MySQL服务器的承载能力。
紧急排查步骤
当出现此故障时，首先需要快速定位当前数据库的状态，以便决定是重启服务还是调整配置。请按以下步骤操作：
1. 查看当前连接状态
登录MySQL服务器，使用以下SQL命令查看当前的连接情况：
SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';
如果 Threads_connected 的值接近或等于 max_connections，则确认连接数已满。进一步可以使用 SHOW PROCESSLIST; 查看所有正在运行的线程，观察是否有大量处于 Sleep 状态的连接，这通常暗示连接泄露；或者观察是否有大量的 Query 状态且耗时较长，这表明存在慢查询阻塞。
2. 检查应用侧日志
联系开发团队，检查应用服务器日志中是否频繁出现 Cannot get a connection, pool error Timeout waiting for idle object 等相关异常，这有助于确认是否是连接池饱和导致的连锁反应。
解决方案与修复指南
方案一：临时调整MySQL连接数上限（治标）
如果确认业务高峰期确实需要更多连接支持，且服务器内存充足，可以临时调大 max_connections 参数。注意，MySQL默认值通常为151，对于生产环境可能偏小。
执行以下命令动态修改（无需重启）：
SET GLOBAL max_connections = 500;
警告： 每个连接都会消耗内存，盲目增加连接数可能导致服务器内存溢出（OOM）而被内核杀死进程。建议根据服务器物理内存大小进行计算，一般建议每个连接占用约2MB-4MB内存（取决于配置），预留足够的OS和其他进程内存。
方案二：优化应用层连接池配置（治本核心）
大多数情况下，问题根源在于应用层的连接池配置不合理。推荐采用 HikariCP 或 Druid 等现代连接池，并进行以下调优：
- 设置合理的最大连接数： 连接池的最大连接数不应超过MySQL
max_connections除以应用实例数量的值。例如，如果有2个应用实例，MySQL限制为500，则每个实例的连接池最大连接数建议设置为200左右，留有余量。 - 启用连接超时检测： 配置
idleTimeout和maxLifetime，确保长期不用的连接能被回收，避免“僵尸连接”占据名额。 - 开启泄漏检测： 在开发或测试环境中开启
leakDetectionThreshold，一旦连接获取后超过设定时间未归还，即记录警告日志，帮助定位代码中的finally块缺失问题。
方案三：代码层修复与慢查询优化
若排查发现存在大量Sleep连接，需审查Java/Python/PHP等代码，确保所有数据库操作都在 try-catch-finally 结构中正确关闭连接（或使用ORM框架自动管理生命周期）。同时，使用 EXPLAIN 分析 SLOW QUERY LOG 中的慢SQL，通过添加索引、优化JOIN逻辑来缩短单次查询耗时，从而快速释放连接资源。
方案四：引入中间件保护
对于架构复杂的企业系统，建议引入Redis等缓存层，减少数据库的直接读取压力。同时，可配置应用服务器的限流策略（Rate Limiting），在数据库连接即将饱和时，对非核心业务请求进行降级或排队处理，防止雪崩效应。
预防建议
- 监控告警： 部署Prometheus + Grafana或使用Zabbix，对
Threads_connected、Threads_running以及连接池利用率设置阈值告警（如超过80%即报警）。 - 定期审计： 每季度审查一次数据库配置与应用连接池参数的匹配度。
- 容量规划： 在新版本上线前，进行充分的压力测试，模拟峰值流量，验证数据库在高负载下的稳定性。
通过上述结构化的排查与优化手段，可以有效解决MySQL连接数超限问题，保障企业核心业务系统的连续性与稳定性。
