凌晨十点，订单服务批量超时：应用等待连接超过5秒后报“获取连接超时”，数据库CPU却一度只有35%。监控显示连接池上限30，连接等待队列堆到800。池虽耗尽，根因却可能是配置失真、慢查询或连接泄漏；盲目调大上限，只会把压力继续推给数据库。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：duoplus（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、先分清池排队与数据库饱和
获取超时只说明连接没有及时拿到，SQL甚至可能尚未发送。评估连接池容量规划，要同时看池内已用、空闲、等待数，以及数据库活跃会话、事务年龄、CPU和IOPS。若等待队列先涨，而数据库仍有余量，优先检查最大连接数是否低于峰值并发、连接创建是否被认证或网络拖慢、校验SQL是否过慢。
把获取超时、队列峰值、数据库会话、慢查询与业务并发放在同一时间线上：队列先涨、数据库后涨，多半是池配置或突发流量先触发；数据库会话和锁等待先涨，再推高队列，应先查SQL。不要只看平均耗时，至少记录P95、P99和最大等待时长。
常见踩坑是把“等待超时”当成“执行超时”，或按实例数直接相乘连接上限。前者尚未进入数据库，后者可能压垮共享库；上限必须受数据库承载能力约束。
二、用事务时间线识别慢查询与连接泄漏
慢查询通常先在数据库侧留下证据：活动会话增长，SQL耗时、锁等待或事务年龄同步升高。查看执行计划、锁链和历史慢SQL，并关注扫描行数与返回行数的比例；长事务识别不能只看单条SQL，还要看从首条SQL到提交的完整年龄；即使没有新SQL，事务也可能持锁或保留旧快照。
连接泄漏更像“借出后不归还”：池内已用连接逼近上限，流量回落后仍不下降，数据库中可见持续增长的空闲会话或idle in transaction。连接泄漏定位可记录借出与归还点的请求标识、连接标识、耗时和未归还代码栈，再核对异常分支、事务边界及ORM生命周期。
判断规则可归纳为：数据库有余量而队列早涨，倾向配置错误；SQL耗时与数据库饱和度同步上升，倾向慢查询；已借出数在低流量期仍不回落，倾向泄漏。证据不足时先做小流量对照，逐项释放事务并观察队列。ServLlama可关联应用池与数据库日志，减少误判。
从等待队列判断瓶颈究竟在哪里
连接池耗尽并不等于数据库已经饱和。请求线程会先进入连接等待队列，只有拿到连接后才进入业务 SQL；如果等待时间持续上升，应同时观察池内活跃连接、空闲连接、等待线程数和获取连接耗时。若活跃数长期贴近上限、空闲数接近零，而数据库 CPU、磁盘 I/O 和锁等待仍有余量，优先怀疑连接被慢 SQL、长事务或业务代码持有，而不是盲目扩大池子。
连接池容量规划不能只看单个实例的 max_size。应以数据库可承受的总并发为上限，扣除运维预留，再按实例数分摊；同时为重试流量和故障切换保留余量，并用峰值压测验证。扩容后若数据库利用率已逼近 100%，等待队列只会更长，并发压力会转移到数据库，形成“池越大，数据库越慢”的正反馈。
连接泄漏定位与长事务识别
连接泄漏定位通常不是“忘记 close”这么简单：异常分支未归还、事务提交后仍占用连接、远程调用跨在事务内，都会让连接长期停留在 active 状态。定位时按连接标识关联应用日志、数据库会话和事务开始时间；若会话建立很早、当前语句长期不变，或事务已经持续数分钟，应标记为长事务识别候选，并追查其持有的锁、临时表和未提交写入。
常见误区是只看数据库饱和度：CPU 或连接数高只能说明负载大，不能证明连接池配置错误；反过来，数据库指标正常也不代表系统健康，因为大量请求可能正卡在池的等待队列。还要区分连接获取超时、SQL 执行超时和数据库锁超时，它们的证据分别来自池监控、链路追踪与数据库等待事件，不能混为一谈。
可执行检查清单：①抓取 10 分钟峰值数据，对齐池活跃数、空闲数、等待队列长度、获取耗时、数据库 CPU、I/O、锁等待和事务时长；②按连接标识与 SQL 指纹找出长期 active 的连接，核对代码中的归还路径、事务边界和重试逻辑；③在压测中逐步调整池上限，观察等待队列与数据库饱和度，确认容量拐点；④为获取连接、执行 SQL 和事务持续时间分别设置告警，并准备回滚扩容、终止长事务和限流预案。每项都要记录时间、样本和处置结果，避免只凭一次瞬时峰值下结论。
喜欢 
顶
难过
囧
围观
无聊
