数据库连接耗尽怎么查：MySQL / PostgreSQL 只读容量脚本与排查手册
下载经过隔离多版本验证的MySQL与PostgreSQL只读容量脚本，用单行脱敏聚合核对最大连接、当前连接、状态分布和近似余量。
先判断连接上限是否真的接近耗尽，再核对连接池、事务、内存、线程、后台进程与最近变更；脚本不会终止会话、修改连接上限或自动扩容。
适用对象
- MySQL卡已在8.0.46与8.4.10验证；PostgreSQL卡已在14.20—18.4验证。
- 两张卡都只返回一行实例级聚合，不输出SQL、库表、账号、应用、地址或会话身份。
- 近似连接余量只是当前快照，不能代替连接池、内存、事务、后台进程和时间线核对。
- 终止连接、调整max_connections、改连接池或扩容都必须单独评估和授权。
两张卡回答什么，也明确不回答什么
只做聚合容量快照，不采集SQL文本、连接身份或业务对象。
先选择与数据库引擎匹配的脚本，再按已验证版本和可见性边界解释结果；任一聚合值都不能直接转化为生产变更指令。
| 引擎 | 已验证版本 | 聚合输出 | 可见性边界 | 不能据此执行 |
|---|---|---|---|---|
| MySQL | 8.0.46、8.4.10 | 当前/运行连接、历史峰值、上限、余量、拒绝计数 | 普通已认证会话；Performance Schema关闭时返回明确状态 | KILL、改上限、改连接池或扩容 |
| PostgreSQL | 14.20—18.4 | 最大/保留连接、客户端连接、活动/空闲、余量 | 缺少pg_read_all_stats时返回insufficient_visibility | 取消/终止backend、改上限或扩容 |
从连接失败到可复查结论的五步
先固定错误、时间窗和影响动作，再运行与版本匹配的只读卡。得到聚合后，必须补充连接池、事务、系统资源和最近变更，最后才决定是应用修复、固定范围巡检、集群管控评估还是单独授权的生产动作。
连接容量故障分流
- 01
01
固定现象
记录错误码、时间窗、影响动作和未受影响范围。
- 02
02
只读快照
运行对应版本脚本，只保留单行聚合。
- 03
03
核对应用
检查连接池上限、获取超时、泄漏候选和发布记录。
- 04
04
核对资源
检查事务、内存、线程/后台进程和集群角色。
- 05
05
授权分流
区分B-HC、集群评估与需另行授权的修复。
任何终止连接、参数修改、写入、切换或扩缩容都不属于公开脚本范围。
什么时候进入巡检、集群管控或应急修复
同一份容量快照可以支持不同层级的下一步，但必须由证据范围和所需授权决定服务路径，不能把公开只读卡包装成自动修复能力。
| 现状 | 下一步 | 交付物 | 授权边界 |
|---|---|---|---|
| 已有脱敏快照，仍无法分级 | B-HC固定范围健康体检 | 风险Top 5、证据缺口、整改顺序 | 不自动改生产 |
| 多节点角色、路由或容量联动 | DMP集群管控评估 | 拓扑与能力边界、实施前置条件 | 不自动部署或切换 |
| 连接已影响生产且需要动作 | 应急远程评估 | 授权范围、动作记录与回读 | 逐项单独授权 |
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
利用率达到多少就必须扩容？
没有适用于所有系统的固定阈值。要结合峰值持续时间、连接池、内存、事务、后台进程、业务增长与故障容忍度判断；公开卡不提供自动扩容结论。
为什么脚本不输出每个账号和连接？
公开入口只需要先判断实例级容量是否值得继续排查。账号、应用、地址和SQL可能涉及客户敏感信息，应在受控范围按最小权限处理。
可以根据脚本直接KILL空闲连接吗？
不可以。空闲连接可能属于连接池或业务会话；终止前还需确认所有者、事务、回滚成本、影响范围和授权。