连接池调大十倍，为什么反而更慢？

连接池保存可重复使用的连接，请求需要操作数据库时借用，用完归还。它省去了反复建立连接的开销，也给应用同时占用多少数据库连接设了上限。这个上限不是数据库同时高效处理多少条查询的保证，更不是在线用户人数。

数据库的 CPU、内存、存储和锁资源仍有限。当更多查询同时争用同一批资源，可能只是把等待从应用里的池，搬到数据库内部。有些负载需要更多并发来覆盖等待，有些负载则会因争抢加剧而变慢，所以不能用一个固定大小回答所有场景。

假设四个应用实例，各自最多二十个连接，配置允许它们合计占用八十个。扩到八个实例而不改池大小，潜在总量就变成一百六十个。滚动更新时新旧实例还可能短暂并存，后台任务、迁移和管理连接也需要留出位置。这里算的是上限，不代表每一刻都建满。

PostgreSQL 17 的 max_connections 限制服务器可接受的并发连接，还影响部分资源的分配。把这个上限调高，不会自动解决慢查询。应用的连接预算应与整个数据库的承载和预留能力协调，而不是每个服务单独决定一个看起来宽裕的数。

先分别记录借连接等待、拿到连接后执行 SQL、事务中其他等待，以及归还连接前的总占用。假设某请求执行 SQL 只用几毫秒，却借着连接等外部接口数秒，那么减少无用占用，可能比开更多连接更直接。还应排查连接泄漏、长事务和慢 SQL。

若等待连接很久，而数据库仍有余力，适当增加池可能有效；若数据库已经繁忙、锁等待增加，继续加大可能扩大拥堵。一次请求甚至可能在持有一个连接时再借另一个，形成资源互等。此时要审查调用和事务结构，不能只靠无止境扩大池掩盖问题。

在可控练习环境中，固定数据量、SQL、并发请求和时间范围，逐档改变池大小。一起比较完成吞吐量、错误、尾延迟、借连接等待与数据库资源；如果只看平均查询时间，可能把排在池外的等待完全漏掉。保留饱和时的表现，也别把轻载结果当作高峰保证。

HikariCP 作者的池大小说明强调实际部署与负载差异，其中的经验公式和旧硬件示例不是普遍最优值。连接等待也要有预算：超过用户请求总时限后，继续无限排队只会累积无用工作。选择一个能满足目标、还有容量余地的范围，比追求“越多越强”更可检验。