凌晨值班时，源站接口错误率从1%升到18%，CPU仍有35%余量，应用连接池的200个连接却全部占满，新请求等3秒拿不到连接；重启后高峰短暂恢复。它常被误判成数据库故障，但根因可能是慢应用、数据库锁等待，或池参数与上游并发上限失配，应先找“谁占着连接”。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：cncsz（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
连接池耗尽不等于连接泄漏：前者是连接都被借出，后者是请求结束后没有归还。要观察活跃连接、空闲连接、等待队列长度和获取连接耗时。活跃数触顶、队列持续增长、请求排队时延同步抬升，才是入口饱和的证据；若队列只在流量尖峰出现，参数失配更可疑。
连接从借出到归还，覆盖的不只是一条SQL。应用若在持连期间调用外部接口、等待锁或处理大对象，数据库很快也会被拖住，这是应用阻塞；若SQL耗时拉长，并伴随会话锁等待或I/O阻塞，慢点才落在数据库。还要核对资源释放机制：事务是否提交或回滚，异常路径是否关闭结果集，连接是否在finally中归还。
别只盯池最大值。上游并发300、每实例池大小200，看似少100个连接就能削峰，但前提是请求能快速归还。若单请求从20毫秒升到2秒，池吞吐会骤降，盲目扩池只会让更多SQL压向数据库。总连接数还应按“单实例池大小×实例数”核算，不能超过数据库上限。
判断时先对齐三组指标：入口看到达速率、在途请求、活跃连接和等待队列；应用看获取连接耗时的p50、p95、p99；数据库看会话状态、锁等待、查询耗时、CPU与I/O。把发布、慢查询和流量峰值叠加比较，不能用单秒快照定责。主机侧采样可交给随身服务器留档，确认故障是否随重启消失。
三种现场可据此判断。数据库查询平稳、无锁等待，但连接长期不归还，且慢接口位于持连代码中，优先查应用阻塞和资源释放。数据库会话大量等待锁，查询p99与事务时长同步上升，根因就在数据库，扩池会放大争用。上游并发突增超过池容量，数据库与应用均正常，队列随流量线性增长，才更像上游并发上限与池参数失配。
压测前固定流量模型，观察每秒完成请求数、连接等待时间和数据库总连接数。扩池后完成量不升、锁等待上升，应撤回参数；队列缩短且p99达标，再校准等待队列长度与超时。不要把连接获取超时当根因，它只是保护信号。池大小、队列和超时必须围绕数据库承载能力联调。
排查时不能只看“活跃连接数”。应用连接池中的请求线程可能正在等待获取连接，或已借出连接却尚未完成上游建连；反向代理和服务端的上游并发上限，也可能先于连接池形成阻塞。两层限制叠加时，等待队列长度会持续上升，但池内连接看似并未打满。应同时采集 active、idle、pending、连接获取耗时，以及上游当前处理数、拒绝数和排队数，并按“取连接建连接等上游业务处理归还连接”拆解耗时。只有把请求排队时延与超时发生位置对应起来，才能确认瓶颈位于连接池、连接建立阶段，还是上游并发控制。
还要核对连接获取超时、网关超时与队列上限的关系。队列无限时，突发流量会不断堆积并放大延迟；队列过短时，请求可能迅速失败。若只看到“池未满”，不能排除池耗尽，因为等待获取连接的请求本身已经形成资源压力。
资源释放机制应覆盖正常返回、业务异常、客户端断开和超时取消等路径，并及时清理事务、响应体及流式任务上下文。任一分支遗漏归还操作，连接就会以“已借出”状态滞留；业务尚未结束也会延迟释放。典型信号是 pending 上升、idle 下降、单连接持有时间增长。可按连接年龄和借用者定位泄漏，再核对连接最大生存期、最大空闲时间与上游 keep-alive 设置是否协调。
直接调大应用连接池并非解法：上游限制不变时，更多连接只会把等待转移到代理侧，甚至压垮下游。盲目延长超时也会延长资源占用，使积压更难恢复。参数调整前应先定位受限层，再用小流量逐步验证池大小、队列上限、连接生命周期和超时组合。
可执行检查清单：①对齐同一时间窗口的 active、idle、pending、连接获取耗时和超时数；②核对池容量、上游并发上限及等待队列长度；③通过压测比较各阶段 P95/P99 时延；④审计成功、异常、取消、超时分支是否归还连接；⑤检查长事务、流式响应和连接持有时长；⑥设定各级超时及队列硬上限；⑦保持上游保护阈值，逐步调整参数并持续观察错误率、拒绝率、时延和资源利用率。
