3. 连接池调优方法论：根据业务并发模型计算最佳连接数、压测与监控指标
连接池调优的核心目标是在避免数据库过载与满足业务并发吞吐之间找到精确平衡点。盲目增大连接数只会加剧数据库上下文切换与锁竞争，反而降低 TPS。本节从并发模型出发，推导最佳连接数计算公式，并给出压测验证与监控指标。
3.1 业务并发模型与连接数计算
连接池大小并非越大越好。根据 Little's Law 与数据库实际处理能力，最佳连接数取决于业务请求的平均响应时间与目标吞吐量。
| 参数 | 符号 | 说明 |
|---|---|---|
| 目标吞吐量 | T (TPS) | 每秒需要处理的请求数 |
| 平均响应时间 | R (秒) | 单个请求从发起到收到响应的平均耗时 |
| 最佳连接数 | C | 连接池应维持的活跃连接数 |
| 数据库 CPU 核数 | N | 数据库服务器可用 CPU 核心数 |
基础公式（Little's Law 变体）：
C = T × R例如：目标 TPS = 1000，平均响应时间 R = 50ms (0.05s)，则 C = 1000 × 0.05 = 50。这是理论最小值，实际需考虑连接复用率与排队等待。
经验公式（考虑 CPU 并行度）：
C = N × (1 + 等待时间 / 处理时间)当请求以 I/O 等待为主时，连接数可适当放大；当请求以 CPU 计算为主时，连接数应接近 N。多数业务场景推荐将连接数设置在 2N ~ 4N 之间。
实践建议： 对于 OLTP 系统，初始连接数可设为
2 × 数据库 CPU 核数，然后通过压测逐步上调，观察 TPS 拐点。当连接数增加而 TPS 不再增长甚至下降时，即为上限。
3.2 压测方法论与步骤
压测是验证连接数设置是否合理的唯一手段。推荐使用 JMeter 或 Sysbench 进行阶梯式压测。
- 基线压测： 设置连接池大小为 1，记录单连接最大 TPS 与响应时间。
- 阶梯递增： 以 2、4、8、16、32、64、128 等倍数递增连接数，每轮运行 5 分钟，记录 TPS、P99 延迟、错误率。
- 拐点识别： 绘制 TPS-连接数曲线，找到 TPS 不再随连接数增长的拐点。
- 稳定性测试： 在拐点连接数下运行 30 分钟，观察连接池活跃数、等待队列长度、数据库 CPU 是否平稳。
压测关键指标：
- TPS / QPS： 系统实际吞吐量。
- P99 延迟： 99% 请求的响应时间，应小于业务 SLA。
- 连接池活跃数： 是否接近配置的最大值。
- 连接等待超时次数： 反映连接池是否过小。
- 数据库 CPU 使用率： 不应持续超过 80%。
3.3 监控指标与告警阈值
生产环境必须建立连接池与数据库的双向监控体系。以下为关键指标及推荐阈值：
| 监控维度 | 指标 | 推荐阈值 | 说明 |
|---|---|---|---|
| 连接池 | 活跃连接数 | < 最大连接数的 80% | 超过则需扩容或优化查询 |
| 连接池 | 等待获取连接超时次数 | 0 次/分钟 | 出现即表示连接池过小 |
| 连接池 | 连接创建/销毁速率 | < 10 次/分钟 | 过高说明连接池抖动 |
| 数据库 | 活跃会话数 | < 2 × CPU 核数 | 超过则可能产生排队 |
| 数据库 | CPU 使用率 | < 80% | 持续超过需排查慢查询 |
| 数据库 | InnoDB 行锁等待 | < 1% 的总事务数 | 锁冲突影响并发 |
3.4 连接数计算与压测流程 SVG
下图展示了从业务并发模型到压测验证的完整调优流程：
3.5 常见调优陷阱与避坑
| 陷阱 | 现象 | 正确做法 |
|---|---|---|
| 连接数设置过大 | 数据库 CPU 飙升，TPS 反而下降 | 按公式 C = 2N~4N 设置，压测验证 |
| 忽略连接泄漏 | 连接池活跃数持续增长，最终耗尽 | 启用 removeAbandoned 与 logAbandoned |
| 压测时间过短 | 未发现连接池抖动或慢查询累积 | 每轮压测至少 5 分钟，稳定性测试 30 分钟 |
| 只关注 TPS 忽略 P99 | 平均延迟低，但部分请求超时 | 同时监控 P99 延迟与错误率 |
重要： 连接池调优不是一次性工作。业务并发模型会随版本迭代、促销活动、数据量增长而变化。建议每季度或每次大版本发布后重新执行压测流程，确保连接数始终处于最优区间。