## 症状现象
网站突然大面积报数据库错误，应用日志刷 Too many connections，连管理工具都登不进数据库——普通连接同样被拒。原因直白：MySQL 的 max_connections 上限被打满，新连接进不来。打满的常见推手：应用连接池配置过大或泄漏、突发流量、长查询堆积占用连接不释放、定时任务并发拉起大量连接。连接数满的连锁反应很快：应用线程池被取连接的动作占满，健康检查也开始失败，雪崩几分钟内完成。
## 应急：先杀长连接救急
普通账号可能连不上，但 MySQL 给具有管理权限的账号预留了额外名额，用 root 管理账号仍可进场：
bash mysql -uroot -p
进场后第一件事临时提升上限，给业务连接腾出位子：SET GLOBAL max_connections=500 动态生效，不用重启实例。随后看现场：
sql SHOW PROCESSLIST;
找两类目标下手：Sleep 状态且时间很长的空闲连接，多半是泄漏；单条执行很久的查询，多半是慢 SQL 拖住会话。KILL 加连接 ID 逐个清理，释放名额，业务先恢复。杀连接前挑准目标，误杀正在写入的会话会让对应事务回滚。
## 根治：查泄漏来源
应急恢复后必须找到源头，否则明天照旧。统计连接分布：
sql SELECT SUBSTRING_INDEX(host,':',1) AS ip, user, COUNT(*) FROM information_schema.processlist GROUP BY ip, user ORDER BY 3 DESC;
哪台机器哪个账号连了几百个，一目了然。去对应应用查连接池配置：最大连接数是否超出配额、是否有代码绕过池直连、是否缺连接超时与空闲回收参数。数据库侧配套调整 wait_timeout 与 interactive_timeout，让僵死的空闲连接自动断开。连接池大小按并发需求乘以平均占用时长估算，盲目调大只是把排队转移到数据库里。
## 预防建议
容量上：应用侧所有实例的池上限之和，必须小于数据库 max_connections 减去管理与备份预留，这条不等式写进部署规范。监控上：连接数水位告警设在上限的八成，提前介入而不是打满再救。顺云控制台的监控配合自定义巡检脚本，连接数、活跃连接、慢查询三个指标一起看，连接数满大多有前兆。压测时同步观察连接数曲线，容量数字靠压测校准，不靠感觉。