凌晨两点，订单服务的数据库连接池上限为 300，运行数触顶后，新请求开始在池内排队，批量报出“等待连接超时”，上游把原本几十毫秒的接口放大成 504。此时直接翻倍池上限很危险：若根因是慢查询、锁等待或网络抖动，更多连接只会继续向数据库施压，延长恢复时间。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：danyun（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
连接池耗尽只表示“暂时拿不到连接”，不能直接推出数据库容量不足。第一类是配置错误：池上限低于应用并发上限，连接创建后未归还，或获取连接的逻辑被放进循环。第二类是数据库过载：CPU、I/O、锁竞争或数据库等待队列拉长，连接已建立却迟迟不能完成业务。第三类是网络阻塞：握手延迟、重传或丢包拖慢建连，池内数字看似正常，实际吞吐却在下降。
可先分流：池内长期满载而数据库平稳，多半是池容量与并发模型不匹配；连接长期 active，且 CPU、I/O、锁等待同时恶化，优先按过载处理；连接创建速率陡增、握手耗时升高，而数据库不繁忙，则更像网络阻塞。还需防范慢查询放大效应：慢 SQL 占住连接，排队请求延长事务，其他实例又补建连接，形成自我强化。
先看等待时长分布，别只看平均值。若获取等待从接近零突然升到超时上限，且 CPU、I/O、锁等待和数据库等待队列同时升高，应按过载处理；若数据库平稳，而瞬时请求数超过应用并发上限，则修正池容量、获取超时与并发控制的比例。再看连接创建速率：低峰仍陡增，并伴随握手失败或重传，瓶颈在链路，不应继续加池。最后看事务持有时长：连接长期 active，但事务只执行短 SQL，要查泄漏或未提交；若长事务与慢 SQL 同时出现，应缩短事务、拆分语句，并确保异常路径提交或回滚。
处置要顺着证据走。数据库有余量且等待源于突发时，按应用实例数乘单实例上限核算连接总量，分批上调池容量并预留管理连接；若数据库已过载，则执行限流：压低应用并发上限，设置有界队列与快速失败，隔离慢接口，停止重试风暴。排查时可用 ServLlama 汇总同时段的应用、连接池和数据库指标，再以小流量压测验证。只加超时、盲目扩池或重试，都会掩盖根因并放大故障。
应用并发上限决定同时进入业务处理的任务数，连接池则决定其中多少任务能立刻拿到连接。连接不足时，请求不会消失，而会进入数据库等待队列：池内无空闲连接，任务持续等待；等待拉长接口响应，又触发上游超时或重试，重试流量再次入队，形成正反馈。因此即使数据库 CPU 不高，服务端仍可能大面积超时。
连接创建速率也会改变故障形态。流量突增或实例启动时，大量连接同时创建，既会消耗连接与网络资源，也可能撞上数据库的连接数限制。创建变慢或失败后，业务若进行重试，数据库等待队列会进一步增长。排查时应把连接创建速率与池等待数放在同一时间轴上比较，而不是只看连接池是否满。
慢查询放大效应常由一条 SQL 引发：执行时间变长，连接归还变慢，活跃连接长期被占用，后续请求随之排队；线程积压又会触发更多并发查询。事务持有时长同样关键，一个长时间未提交的事务即使没有慢查询，也会持续占用连接和锁。
不要把“连接池已满”直接等同于“数据库容量不足”。满池可能来自慢 SQL、长事务、锁等待，也可能来自应用并发失控。只调大池容量，可能把压力直接推给数据库；盲目重启应用虽能暂时清空连接，却会掩盖根因并造成冷启动。
检查时按顺序执行：① 对照应用并发上限、当前 QPS、池大小与等待队列，确认瓶颈位于线程、连接还是数据库；② 查看连接创建速率的突增区间，关联创建失败、超时和重试；③ 找出最慢 SQL 与最长事务，核对事务持有时长、未提交事务、行锁和锁等待；④ 查看数据库 CPU、I/O、活跃会话及连接上限；⑤ 先限制重试、隔离慢 SQL、缩短事务，再依据数据库承载能力调整池大小。
排障目标不是单纯扩大连接池，而是让连接周转速度、事务持续时间与数据库处理能力重新平衡。发现等待队列持续增长时，应先阻止新增并发和无退避重试，再释放被阻塞的事务与连接；确认数据库余量后，才逐步提高应用并发上限。
