连接池告警不等于数据库连接数太少。应用可能把连接借出后未归还，查询或事务执行过久，也可能是实例扩容后连接总量超过数据库上限。有效的云数据库连接池耗尽的定位与容量修复，要先找出连接卡在哪里，再决定调应用池、优化查询还是提高数据库容量。
先记录告警时间、受影响的服务和数据库，再对照应用池等待指标与数据库活动连接数。两边数据能否对应，是区分“池内拥堵”和“数据库接近上限”的关键。
先判断连接耗尽发生在哪一层
应用连接池通常能提供活跃连接、空闲连接、等待连接数、获取连接等待时间等指标；数据库侧则查看当前连接、连接上限、活跃会话和会话状态。MySQL 可检查进程列表及连接相关状态，PostgreSQL 可查看 pg_stat_activity 和 max_connections。
- 池内活跃数接近上限，数据库仍有余量：检查慢查询、锁等待、长事务，以及连接是否未关闭。
- 数据库连接数接近上限，多个应用池同时等待：核算所有服务实例的连接总量，留意后台任务、管理工具和迁移程序。
- 连接数随流量突增，流量回落后下降：检查突发请求、重试风暴及实例自动扩容时连接池是否同步放大。
不要只看平均值。短时峰值、等待时间分位数和长时间占用的连接，往往比日均连接数更能解释故障。
按团队职责选择定位方法
应用开发团队：查借出与归还链路
检查数据库访问代码是否在异常、超时和提前返回时仍能释放连接；Java 项目使用 HikariCP 时，可关注连接获取超时、池内活动连接和连接使用时长。把连接使用时长与慢查询日志、应用调用链对齐，优先修复长查询和未结束事务，而不是直接扩大池。
数据库团队：找慢会话与锁等待
按会话持续时间、事务状态和等待事件排序，区分正在执行的查询与空闲但仍处于事务中的会话。先确认 SQL、锁链和事务边界，再评估索引或语句改写。终止会话前应核实业务影响；反复终止而不修原因，通常只会暂时释放连接。
平台运维团队：核对实例数与总连接预算
连接池上限必须按所有应用实例汇总，而非只看单实例配置。例如，6 个实例各允许最多 20 个连接，理论上就可能申请 120 个；还要给其他服务、运维访问和故障处理留出余量。应用自动扩容后实例数增加，固定的单机池上限也会推高数据库总连接需求。
数据分析团队：分开交互查询与批处理
报表、导出和批量任务常因扫描数据量大而长期占用连接。可将批处理安排在低峰时段，限制并发，并为长任务设置合理超时；不要让突发报表与在线请求无节制共享同一连接预算。若使用只读副本，也需分别监控副本连接上限与查询负载。
小型团队：先止损，再做容量调整
人手有限时，先降低非关键任务并发、暂停重复重试，并确认服务恢复；随后补齐应用池和数据库的基础监控。连接池代理如 PgBouncer 可在适用的 PostgreSQL 场景中复用服务端连接，但事务池化会影响依赖会话状态的用法，启用前要验证临时对象、会话变量等功能是否兼容。
可执行的定位与扩容顺序
- 固定故障窗口：记录应用等待连接的时间、活跃与空闲连接数，并采集数据库连接数、慢查询和锁等待。
- 对齐连接归属：按应用、实例和任务类型统计连接，确认是否有连接泄漏、长事务或某个服务突增。
- 估算总预算：用“实例数 × 单实例池上限”计算应用理论最大连接数，再加上其他客户端需求；与数据库可用连接额度比较，并预留运维和波动空间。
- 先修占用问题：优化慢 SQL、缩短事务、修复连接释放和重试策略。适当设置获取连接超时，避免请求无限排队；具体值应依据接口时限和业务容忍度测试。
- 分阶段扩容：确认云数据库规格或参数支持后，再提高连接上限或实例容量，并同步调整应用池。小幅变更后观察等待时长、数据库负载和错误率，避免一次性把池开到过大。
池上限并非越大越好：连接过多会增加数据库调度、内存及上下文切换压力；池过小则可能在短时并发下排队。修复后复盘峰值和连接持有时长，按实际负载确定配置。这样做，云数据库连接池耗尽的定位与容量修复才不会退化成单纯改大数字。
常见问题
应用池已满，是否一定要调大？
不一定。若连接长期被慢查询或未结束事务占用，应先修占用原因；只有确认数据库仍有余量且并发需求合理时，才考虑提高池上限。
提高数据库最大连接数就能解决吗？
不一定。更高上限可能加重数据库资源压力。先算清全部应用实例的连接预算，并检查实例规格、会话负载和连接使用时长。
连接池代理适合所有场景吗？
不适合。代理能帮助复用连接，但不同池化模式对会话状态有不同限制。需要结合数据库类型、驱动和应用行为验证。
扩容后还要观察哪些指标？
观察连接获取等待时间、活跃连接、数据库负载、慢查询、锁等待和请求错误率；同时确认连接总量没有随实例扩张而失控。
