4. 连接池调优方法论：基于 TPS/QPS 的池大小计算公式与压测验证

连接池大小并非越大越好。过大的连接池会导致数据库上下文切换频繁、连接争用加剧，反而降低吞吐量；过小的连接池则会造成请求排队，增加响应延迟。本节给出基于 TPS/QPS 的量化计算公式，并配套压测验证流程，帮助你在生产环境中找到最优连接池大小。

4.1 核心公式：从 TPS/QPS 推导连接池大小

连接池大小的计算需要同时考虑应用层的并发请求量（TPS/QPS）和单个数据库连接的耗时。以下是业界通用的推导公式：

更精确的工程化公式（考虑连接等待队列）：

// 最小连接数 = 峰值 TPS × (单连接处理时间 + 网络延迟)
// 最大连接数 = 最小连接数 × (1 + 等待容忍系数)
// 等待容忍系数：0.2~0.5，取决于业务允许的排队深度

// 示例：峰值 TPS = 2000，单连接处理时间 = 5ms，网络延迟 = 2ms
// 最小连接数 = 2000 × (0.005 + 0.002) = 14
// 最大连接数 = 14 × 1.3 ≈ 18

4.2 不同场景下的连接池参数对照

4.3 压测验证方法：三步确认最优值

公式计算出的连接池大小只是理论起点，必须通过压测验证才能确定生产配置。推荐以下三步验证流程：

1. 基准压测：使用 JMeter 或 Gatling 模拟峰值 TPS 的 80% 负载，连接池从最小值开始逐步递增（步长 5），记录每次的 TPS、P99 延迟、数据库 CPU 使用率。
2. 拐点识别：绘制“连接池大小 vs TPS”曲线，找到 TPS 不再随连接数增加而增长的拐点。该拐点对应的连接数即为理论最优值。
3. 边界验证：在最优值基础上增加 20% 和减少 20% 分别压测，确认系统在波动负载下仍保持稳定，无连接超时或线程阻塞。

4.4 连接池大小与 TPS 关系的典型曲线

下图展示了连接池大小与系统吞吐量（TPS）之间的典型关系，帮助理解拐点概念：

4.5 压测工具与关键指标采集

推荐使用以下工具组合完成压测验证：

• JMeter：配置线程组模拟并发用户，添加 JDBC Request 采样器，使用监听器记录聚合报告。
• HikariCP 监控：通过 HikariConfig.setMetricsTrackerFactory() 暴露连接池活跃数、等待队列深度、超时次数等指标。
• 数据库端监控：使用 SHOW PROCESSLIST 或数据库性能监控工具（如 MySQL Performance Schema）观察连接数、活跃查询数、锁等待情况。

// 线程组配置
线程数：50
Ramp-Up 时间：10 秒
循环次数：100

// JDBC Connection Configuration
Database URL: jdbc:mysql://host:3306/db?useSSL=false
JDBC Driver Class: com.mysql.cj.jdbc.Driver
Username: test
Password: test
Max Connections: 20  // 与连接池大小对应

// JDBC Request
SQL Query: SELECT * FROM quartz_jobs WHERE status = 'WAITING'
Parameter values: (无)
Variable names: result
Result variable name: queryResult

4.6 连接池调优与 Quartz 调度平台的协同考量

当连接池用于 Quartz 调度平台时，需要额外关注以下协同点：

下图展示了连接池调优与 Quartz 调度平台之间的协同关系：

4.7 压测结果判定标准

完成压测后，根据以下标准判定连接池配置是否达标：

• TPS 达标：实际 TPS ≥ 目标 TPS 的 95%，且未出现明显下降趋势。
• 延迟达标：P99 延迟 ≤ 目标延迟的 1.5 倍，P999 延迟 ≤ 目标延迟的 3 倍。
• 连接池健康：活跃连接数 ≤ 最大连接数的 80%，等待队列深度 ≤ 5。
• 数据库健康：数据库 CPU 使用率 ≤ 70%，无大量锁等待或慢查询。