接口等待很久后报超时，可能在等待连接，也可能已经连接却执行 SQL 缓慢。统一把超时值调大，会增加请求积压并掩盖真正的瓶颈。
连接池限制同时借出的连接数。获取连接等待、驱动连接建立、SQL 执行和事务持锁属于不同阶段；长事务、连接未归还以及并发突增，都可能耗尽可用连接。
一、问题的范围与前提
应用配置、依赖注入、连接池和事务共同决定运行结果。启动日志没有异常，不代表业务依赖都已就绪。外置配置与包内默认值可能不同，实际使用的连接、Profile 和运行入口应先被确认。
二、技术分析与方案取舍
获取连接超时常表示池内没有可借用资源，而 SQL 超时表示连接已经获得后执行受阻。前者可结合 active、idle、pending 等池指标分析，后者需查看数据库活动、锁和计划。长事务或未归还连接会把其它请求拖入等待。扩大池容量之前，先估计数据库能承受的并发，再比较尾延迟与错误；否则可能把等待从应用池转移到数据库内部。
将环境配置从业务代码中分离，约束线程、连接和请求时间预算。数据库连接要在明确作用域内归还，事务异常有清晰回滚规则。对外接口和后台任务分别管理状态，不能仅依赖一个方法返回值描述跨系统完成情况。
三、实现与排查的顺序
- 对齐请求与池状态时间。
- 区分获取连接和执行阶段。
- 检查连接借出与归还。
- 结合数据库活动定位长事务。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
请求开始 → 获取连接 → 执行 SQL → 提交/回滚 → 归还连接
每段保留：开始、结束、错误类型与请求身份
这是连接生命周期示意。获取连接的等待和 SQL 执行等待使用不同配置，归还必须覆盖异常出口。观察连接活跃、等待与数据库活动，才能判断扩大池容量是否有收益。
四、验证和结果解释
从实际请求关联池状态、SQL 和异常堆栈，先找首个有效失败，再检查后续连锁错误。配置调试只公开非敏感来源与结构，不无差别开放环境或管理端点。并发负载使用固定输入和数据规模，避免环境变化影响比较。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 高峰时等待时间有上界 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 异常分支能及时归还资源 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 增加池大小不会压垮数据库 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
验证正常启动、依赖不可达、连接耗尽与异常回滚。增加池容量不能替代数据库治理，放大超时也可能增加积压。版本变化时配置和依赖一起核对，不能以旧框架文档解释所有新运行行为。
五、适用边界与结论
连接池不是数据库吞吐的无限放大器。需要先查数据库最大连接和资源预算，不能用大量空闲连接替代对慢查询的治理。
这条路径把“对齐请求与池状态时间”与“结合数据库活动定位长事务”连在一起，中间保留可复查的条件。实施时优先确认“高峰时等待时间有上界”，再检查“增加池大小不会压垮数据库”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
