20:17，订单接口批量报“获取数据库连接超时”。单实例 12 个活跃连接等于池上限，请求等待 30 秒；数据库全局连接只有 186，尚未到 200。此时直接把各实例池上限从 12 调到 20，可能让更多连接冲向数据库，反而触发超限。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：liteserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先分清：连接被谁占住，为何不释放，数据库是否还有接纳新会话的余量。池满、数据库上限已到、慢查询堆积都会表现为取不到连接，但根因与处置顺序不同。
随身服务器可汇总各实例的连接池、进程与事务快照，为扩容提供时间线。
数据库上限是全局准入边界，受最大连接数、内存与工作进程约束；接近它时，新会话会排队或报错。应用连接池是实例自己的边界，连接全忙时，等待发生在应用侧，数据库总连接仍可能安全。慢查询堆积是占用来源：连接在跑慢 SQL、等待锁或被长事务牵连后迟迟不归还。
所以，达到活跃连接阈值只能确认症状。空闲连接复用正常时，高峰过后活跃数会回落；连接长期使用中，则查泄漏、事务边界和等待链。数据库侧还要看全局会话、新建连接失败、CPU、I/O 与锁等待，不能把池上限当成数据库上限。
先看同一时间窗：池活跃数、等待队列、获取耗时、数据库会话、查询 p95 和锁等待。总连接逼近 200 且新建会话失败，优先判定为数据库上限；数据库不拥挤而各实例卡在池上限，优先判定为连接池饱和度；活跃连接、查询耗时与锁等待同步上升，则优先怀疑慢查询堆积。至少核对 5 分钟趋势，别用瞬时点下结论。
再做进程观测：记录池等待数，抓取线程栈，区分使用中、空闲未复用和获取中的连接，并记录最老事务年龄。随后按事务开始时间定位长事务滞留，关联执行 SQL、锁链与等待事件。未确认事务是在运行、排队还是持锁前，不应先扩池。
止堵与扩容也要排序：慢查询或锁堆积时，先取消失控查询、缩短事务、修复索引或阻断持锁源头，再增加副本；池先饱和时，先修泄漏、恢复空闲连接复用，再按数据库余量小步扩池；数据库上限先到时，先限流、复用持久连接并止住长事务，再评估数据库扩容。常见踩坑是只调大池上限、频繁重启或只看活跃数，都会放大拥塞。
连接池耗尽不等于数据库连接数不够，更常见的是连接借出后迟迟不能归还。诊断时应把连接池饱和度与数据库活跃会话放在同一时间轴观察：池使用率逼近 100%、等待队列增长，而数据库仍有余量，通常说明问题在应用侧，如连接泄漏、归还异常或池容量偏小；若活跃会话也逼近活跃连接阈值，则应继续追踪慢查询堆积、锁等待和长事务滞留。
空闲连接复用是否正常，是判断周转效率的关键。健康的连接池应复用空闲连接，而不是每次都新建；但连接失效检测缺失、网络抖动或生命周期配置不合理，会使旧连接使用时才报错，连续重建又可能造成数据库连接抖动。应记录连接创建时间、最后使用时间、获取耗时、等待次数和归还耗时，确认高峰时是“无可用连接”还是“连接不可用”。
慢查询堆积会让活跃连接长期占用，锁等待会使事务无法提交，长事务还可能持有锁和快照，进一步放大慢查询。数据库中的事务持续时间、等待事件、执行计划与历史查询耗时，应和接口耗时、事务边界逐一对应，避免只看慢查询列表就下结论。
常见误区包括：直接调大数据库最大连接数，却未核算连接池总容量和数据库承载能力；只延长连接获取超时，掩盖慢查询或长事务；把连接归还视为事务提交，忽略后台任务仍持有事务；以及重试在网关、应用和数据库间叠加，压垮同一资源。定时任务还应与在线业务分池，避免相互抢占。
可执行检查清单：一、连续采样池饱和度、活跃数、空闲数、等待队列和获取连接耗时；二、定位占用最久的 SQL，核对索引、扫描行数、执行计划及锁等待；三、列出异常长事务，找到未及时提交或回滚的代码路径；四、核对最大生命周期、空闲超时和失效检测，确认空闲连接复用正常；五、检查各层重试策略；六、在低峰期逐项调整，每次只改一个参数，并复测数据库 CPU、IO、锁等待、连接错误率与接口延迟。
最终目标不是让连接数更多，而是让连接快速借出、正确归还。把池指标、数据库会话和业务请求按同一链路关联，才能确认瓶颈位于连接池配置、数据库执行能力还是事务设计，并形成可回滚的修复方案。
