连接池对性能的影响
连接池把昂贵的连接建立过程复用起来：应用启动即建好一批连接，请求到来时借出、用完归还。池太小，请求在池外排队，等待时间高企；池太大，数据库侧连接数被打满，连累所有租户。性能测试里连接池是最常被忽略的旋钮之一——不测它，你不知道满载时到底是应用慢还是排队慢。
基本信息
| 核心参数 | 最大连接数、最小空闲、获取连接超时、空闲回收时间 |
|---|---|
| 估算法则 | 所需连接数约等于峰值并发数乘以单请求持有时长除以请求间隔 |
| 连锁参数 | 数据库最大连接数、各服务池总和、代理层限制要一起核对 |
| 等待信号 | 获取连接的等待时间是最直接的池压力指标 |
| 超时设计 | 获取超时要有明确上限且短于上游超时，避免请求无限挂起 |
| 健康检查 | 空闲连接保活，避免网络中断后拿到失效连接 |
典型使用场景
- 压测调优：并发上不去时先看池等待还是数据库饱和，再调参数。
- 故障复盘：数据库连接数打满引发全站超时，回溯池配置与泄漏。
- 微服务编排：多个服务共享数据库时，按配额分配各自池上限。
- 发布切换：数据库主从切换后，池内旧连接失效，验证重连行为。
- 长事务排查：慢查询占住连接不还，池被拖干，定位泄漏源头。
指标与判读
| 指标 | 含义 | 异常信号 |
|---|---|---|
| 活跃连接 | 正在被使用的连接数 | 长期贴顶说明池不够或持有过久 |
| 等待时长 | 获取连接的排队时间 | 非零且增长即池压力 |
| 空闲连接 | 池中闲置数量 | 长期为零且活跃贴顶 |
| 获取失败 | 超时拿不到连接 | 直接表现为业务报错 |
| 数据库总连接 | 服务端视角的连接数 | 接近上限则各方都受影响 |
连接池不是越大越好：过大把压力透传到数据库，反而降低整体吞吐并放大尾延迟。
统计口径要含等待：只看 SQL 执行时间会漏掉排队时间，性能结论偏乐观。
严防连接泄漏：拿到连接未在异常路径归还，池会随运行时间逐渐枯竭。