Too many connections 表示数据库无法接受新连接。直接提高 max_connections 可能暂时恢复，却会增加内存和并发压力，甚至把连接问题升级为数据库雪崩。
一、确认连接现状
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW VARIABLES LIKE 'max_connections';
SHOW FULL PROCESSLIST;Threads_connected 是已建立连接，Threads_running 才是正在执行的线程。连接多但运行少，常见于连接池过大、连接泄漏或 Sleep 连接长期不释放。
二、按来源和状态统计
SELECT USER, HOST, DB, COMMAND, COUNT(*) AS cnt
FROM information_schema.PROCESSLIST
GROUP BY USER, HOST, DB, COMMAND
ORDER BY cnt DESC;定位是哪个应用、实例或账号占用连接，再结合发布时间、流量和应用日志判断连接池配置或泄漏。
三、检查慢 SQL 与锁等待
SHOW ENGINE INNODB STATUS\G
SELECT * FROM performance_schema.data_lock_waits;慢查询和锁等待会让连接迟迟不能归还。此时增加连接上限只会让更多请求进入数据库。应先处理阻塞事务、异常 SQL 和下游超时。
四、紧急止血
限流或摘除异常应用实例；
终止明确无用的 Sleep 或阻塞会话；
回滚导致连接增长的版本；
临时调整连接上限前评估每连接内存和主机余量；
保留管理连接，避免 DBA 也无法登录。
不要批量 Kill 未确认的业务事务，可能造成回滚压力和数据影响。
五、连接池治理
各应用连接池总和不能简单超过数据库上限。设置合理的最小、最大连接数、获取超时、空闲回收和连接最大生命周期。连接获取失败时应快速失败或降级，避免线程无限等待。
六、监控与预防
监控连接使用率、运行线程、连接创建速率、拒绝次数、慢查询、锁等待和数据库内存。按应用使用独立账号，便于统计、限额和审计。发布前通过压测验证连接池与数据库容量。
总结
连接耗尽的根因通常在应用连接池、连接泄漏、慢 SQL 或锁等待。应先按来源定位并恢复业务，再调整连接池和容量模型，而不是把 max_connections 当作永久答案。