直接答案：先保留管理连接，记录 Threads_connected、Threads_running、连接来源、状态、事务和慢请求，确认是业务峰值、连接池配置、泄漏、长事务还是数据库变慢造成的积压。紧急时可限流或摘除异常应用实例；只有算清每连接内存、数据库全局缓存、系统余量和后端承载能力后，才考虑调整 max_connections。
本文于 2026 年 9 月按官方文档核对。命令和配置只展示判断方法，不代表可在任意生产环境直接复制；发行版、云平台、网络拓扑和业务写入不同，执行前必须确认对象、权限、备份和带外恢复入口。
专属资产：连接预算公式与紧急/长期分栏
| 现象/阶段 | 要判断什么 | 需要的证据 | 安全边界 |
|---|---|---|---|
| 连接高、运行线程低 | 大量空闲连接 | processlist与连接池 | 缩短池和空闲超时 |
| 连接与运行线程都高 | 并发SQL或积压 | 慢日志、锁和CPU/IO | 先修查询或限流 |
| 单一来源暴增 | 实例重试或泄漏 | host/user/program_name | 摘除异常实例 |
| 长事务 | 连接长期占用并阻塞 | 事务年龄与锁等待 | 按业务确认后终止 |
| 达到上限且管理失败 | 无保留管理容量 | admin接口/额外端口 | 先恢复受控管理通道 |
这张表要求每个结论至少有两个相互独立的证据，例如“服务监听+外部连接”“设备延迟+业务耗时”“备份文件+隔离恢复”。单一控制台绿灯、单次截图或一个User-Agent都可能误导，不能作为完成依据。
为什么常见的一键处理容易失败
运维问题通常跨越控制台、操作系统、应用和外部依赖。重启、全放行、清缓存或重装会改变多个变量，并可能清掉最有价值的现场。正确顺序是先定时间线和影响范围，再确认最靠近故障的证据层，最后做可回滚的最小动作。
对于有数据库、订单、表单、队列或用户上传的站点，还要先判断当前是否仍在写入。回滚旧快照、切回旧主机或恢复旧数据库前，必须处理变更期间的新数据；否则技术状态恢复了，业务数据却可能倒退。
六步安全执行流程
1. 确认对象与基线
记录错误时间、应用版本、流量和当前连接指标；优先使用受控管理员通道，避免反复重启MySQL清空证据。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
2. 保留恢复入口
按用户、来源、数据库、命令和状态汇总连接，区分Sleep、执行、锁等待和长事务；完整SQL与账号信息应脱敏保存。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
3. 取得直接证据
检查应用池的最大/最小、获取超时、空闲回收、连接寿命和泄漏检测。多个应用实例的池上限相加，必须小于数据库可用预算。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
4. 只做最小变更
关联慢查询、锁、CPU、内存和磁盘延迟。数据库变慢会让连接归还更慢，连接数只是结果，盲目加大上限会扩大排队。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
5. 验证业务与副作用
紧急缓解按顺序考虑限流、暂停非核心任务、摘除异常实例，再按业务确认终止特定会话；不要批量kill未知事务。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
6. 重启或跨峰复验
修复后用同一并发模型测试，确认连接池稳定、Threads_running不过度增长、无泄漏告警、尾延迟和错误恢复，并跨过一个真实高峰。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
不应直接照做的五种处理
- 直接把max_connections调到几千
- 重启数据库代替定位来源
- 批量kill包含写入的长事务
- 每个应用实例都配置同样大池
- 只看连接数不看Threads_running
这些做法并非永远错误，而是缺少适用条件。若确需执行，应在变更单中写清目标、影响范围、停止阈值、备份位置、回滚命令和预计恢复时间；高风险动作先在副本或小流量上演练。
回滚触发与数据边界
出现核心写入失败、持续5xx、管理员入口丢失、数据校验不一致、尾延迟越过停止阈值或监控失明时，应停止继续扩大变更。回滚前确认新旧环境各自产生了哪些写入，保留日志和配置差异；回滚后用相同请求和同一时间窗口重测，而不是只看首页恢复。
如果故障根因尚未确认但必须先恢复服务，可以采用限流、摘除单节点、恢复上一配置或临时切流等缓解措施，并明确它只是临时处置。恢复后仍要完成根因分析和复发验证，不能把“重启后正常”写成最终原因。
验收清单
- [ ] 连接来源可归属
- [ ] 池上限总和有预算
- [ ] 无持续增长的Sleep
- [ ] 慢SQL与锁已处理
- [ ] 内存峰值有余量
- [ ] 保留管理入口可用
- [ ] 相同负载错误消失
- [ ] 跨峰连接能回落
验收应由另一位维护者按记录复现至少一项关键检查，并覆盖重启、真实高峰或等价受控负载。所有失败项都记录实际值与时间，不使用“基本正常”“应该没问题”作为关闭条件。
相关资料与隔离测试入口
站内可继续参考内存不足与OOM、CPU100排查、监控告警。需要搭建副本验证配置时，可查看美国轻量云和美国弹性云服务器的实时规格；先确认库存、价格和适用条件，不把测试环境当备份或生产容灾。
常见问题
max_connections越大越好吗？
不是。更多并发会消耗内存并增加锁、CPU和IO竞争。上限应由应用池、单连接风险和数据库吞吐共同决定。
Sleep连接是不是都能杀？
不一定。它可能是连接池正常保留。应看空闲时长、来源、事务状态和池配置，避免杀掉仍持有事务的会话。
重启MySQL能解决吗？
能暂时释放连接，但会中断业务并丢失现场。泄漏、重试风暴或慢SQL未修复会快速复发。
连接池应该设多大？
以数据库可承载的活跃并发为上限，再在多个实例间分配，并保留管理和批任务容量。应用线程数不是直接答案。
Too many connections为何偶尔出现？
可能是短时流量、上游变慢、网络重试或定时任务重叠。需要高分辨率连接、错误和延迟时间线，平均值会掩盖尖峰。