连接池参数调优原则：根据并发量与数据库响应时间

连接池调优，说白了就是回答两个问题：给多少连接合适？ 和 连接怎么管最稳？
很多新手一上来就调大最大连接数，觉得越多越快。嗯，我早年也这么干过，结果数据库直接被拖垮了。
这一章咱们聊聊调优的真正原则——基于并发量和数据库响应时间来做决策，而不是凭感觉。

调优的核心指标

我个人习惯先盯住两个数字：并发数和数据库平均响应时间。
前者决定你需要多少连接，后者决定连接能多快被释放。

• 并发数（T）：同一时刻请求数据库的线程数量。
• 平均响应时间（R）：一个数据库请求从发出到返回的平均耗时，单位毫秒。
• 目标连接数（C）：理想情况下的连接池大小。

这里有个经典估算公式：

C = T × (R / 1000) × (1 + 冗余系数)

举个例子。我之前的项目，峰值并发 200，数据库平均响应 50ms。套用公式：
C ≈ 200 × 0.05 × 1.2 ≈ 12。
是不是比你想象的小很多？很多团队上来就给个 200 连接，结果数据库光上下文切换就耗掉 30% 的 CPU。

根据并发量调优

并发量是动态的。我建议按日峰值并发去算，别拿平均值糊弄。

并发量区间	推荐最小连接数	推荐最大连接数	注意事项
< 50	5	15	空闲回收时间设短一点
50～200	10	30	关注数据库的 CPU 和连接数曲线
200～1000	20	50	必须启用连接池监控
> 1000	30	80	考虑读写分离或缓存前置

为什么最大连接数不建议超过 80？我跟你讲个真实教训。
以前有个金融项目，DBA 把连接池最大设到 300。结果高峰期数据库 CPU 直接飙到 95%，大量连接在排队等锁。最后降到 60，吞吐量反而提升了 40%。
说白了，连接多了，锁竞争和上下文切换会把数据库拖死。

根据数据库响应时间调优

响应时间直接决定了连接的周转效率。响应时间越长，连接占用越久，需要的连接数就越多。

• R < 10ms：连接周转极快，少量连接就能撑住高并发。最小连接数可以设小一点。
• R 在 10ms～100ms：常规区间，按公式估算，注意监控连接等待率。
• R > 100ms：说明数据库本身有瓶颈。这时候加连接治标不治本，得先优化 SQL 或加缓存。

我习惯在压测时把响应时间和连接池使用率放在同一个监控面板上。
如果发现连接池使用率超过 80%，同时响应时间还在上升——说明连接数不够用。但如果使用率低于 30%，响应时间却很高——说明问题不在连接池，在数据库内部。

其他关键参数调优

除了大小，还有几个参数我每次调优都会过一遍。

参数	作用	我常用的推荐值	说明
connectionTimeout	获取连接的最大等待时间	3000～5000ms	超过这个时间直接报错，避免请求堆积
idleTimeout	空闲连接存活时间	60000ms	对突发流量友好，又不浪费资源
maxLifetime	连接最大存活时间	1800000ms（30分钟）	避免长时间连接被数据库端断开
validationQuery	连接存活检测 SQL	SELECT 1	一定要轻量，别用复杂查询

我曾经遇到过一个坑：maxLifetime 设得比数据库的 wait_timeout 还长。
结果连接被数据库端断开后，连接池不知道，还在继续用。应用层时不时抛出异常，查了两天才定位到。
嗯，从那以后我每次调优都会先检查数据库的 wait_timeout 和 maxLifetime 对齐。

调优的决策流程

下面这张图是我自己在项目中梳理的调优决策流程。每次改动参数前，先走一遍这个流程，很少出大问题。

这张图的逻辑其实很简单：先拿到数据，再算理论值，然后压测验证，最后按反馈微调。
我每次调优都严格按照这个循环走，从不跳过压测。

几句实在的

连接池调优，本质上是在资源供给和系统稳定性之间找平衡。
你想想看，连接不是越多越好，也不是越少越好。少了请求排队，多了数据库扛不住。
我个人习惯是：

• 先监控，再估算
• 先压测，再上线
• 先稳定，再调优

参数调优没有银弹，但只要抓住了并发量和响应时间这两个根指标，方向就不会偏。
嗯，下一把调优的时候，记得先把这两个数字摆在桌面上。