连接耗尽可能来自请求过多、连接持有过久、异常重试或闲置连接管理。提高上限也会增加资源需求，不能替代慢查询和业务并发分析；应把连接状态、应用请求和数据库容量按同一时间范围观察。
先确认是达到哪一类限制
保存数据库错误、连接状态与主机配额信息，区分服务器总连接、账号限制和代理连接池。一个WordPress报错并不意味着整个实例都满，也不能用后台当前连接数低否定前一时刻的峰值。记录发生时间与持续情况，避免只看瞬时截图。
查看连接在做什么和等什么
活动查询、等待锁与空闲连接消耗和处置方式不同。将脱敏后的状态与请求路径对应，找出是否有长事务、外部等待时仍持连接或失败后快速重试。进程列表可能包含客户数据和SQL，应受控保存，不能公开完整内容证明问题。
先处理持有和重试原因
缩短经证实不必要的连接占用、修复查询或事务问题，比单纯允许更多等待更有价值。账号或池配置按实际运行环境调整，避免随意结束所有连接导致业务回滚。若确需提高上限，应核算整机与数据库每连接资源，不承诺无限承载。
验证峰值与错误恢复
在代表性访问条件下观察连接峰值、持续时间、错误和响应，确认修改后没有把压力转移成内存不足。检查失败请求是否安全重试而不重复订单或通知。报告应说明已观察时段和业务范围，不能由一次连接成功保证长期不会再耗尽。
关键区别
连接上限：允许的连接数量边界；不是处理能力保证。
连接持续时间：影响资源被占多久；慢查询可能拖长占用。
重试策略：失败后的再次请求；可能放大瞬时压力。
怎样确认处理到位
连接数与请求耗时的变化可以解释，目标错误减少且资源仍有余量，失败恢复没有造成重复业务或其他账号受损。
容易误判的边界
不要未经分析批量终止数据库连接或无限提高上限；空闲、执行和锁等待需要不同处置。
