每次访问数据库都新建 TCP 连接，代价是握手、认证、资源分配，开销远高于查询本身。连接池把连接复用起来，是每个高并发应用的基础设施。本文讲清它的原理和调优方法。
一、为什么需要连接池
以 MySQL 为例，建立一条连接的过程包括 TCP 三次握手、MySQL 协议握手、认证、权限校验。在高并发下，如果每条请求都现场建连，数据库会被建连开销和连接数上限拖垮。
连接池维护一组「已建立且可复用」的连接，请求借出一用一还，把建连成本平摊到大量请求上。
二、核心参数
以 HikariCP 为例，几个关键参数的含义：
| 参数 | 含义 | 建议 |
|---|---|---|
| maximumPoolSize | 池中最大连接数 | 不是越大越好，见下文 |
| minimumIdle | 最少空闲连接数 | 与峰值无关，主要减少冷启动 |
| connectionTimeout | 等待连接的超时时间 | 30s 左右 |
| maxLifetime | 连接最大存活时间 | 应小于数据库 wait_timeout |
三、常见的误区：连接数越大越好？
不是。当连接数超过数据库 CPU 核心数的一定倍数后，线程切换开销会反超收益。业界推荐经验公式：
连接数 ≈ CPU 核心数 × 2 + 磁盘数（HDD）更准确的做法是压测：逐步增加连接数，观察吞吐量拐点。连接数过多时，数据库等待队列变长，响应时间反而上升。
四、调优方法
- 先压测拿到基线：用压测工具模拟真实流量，记录不同连接数下的 QPS 与 P99 延迟。
- 找吞吐拐点：从默认值开始，按比例增减 connectionTimeout。QPS 不再增长、延迟开始上升的点，就是最优点。
- 检查连接生命周期：maxLifetime 必须小于数据库侧的空闲超时（如 MySQL 的 wait_timeout），否则会被数据库主动断开，出现「连接失效」异常。
- 监控池内指标：关注借用超时、连接获取等待时间。如果频繁等待，先看是否池子太小，而不是盲目调大。
五、连接池以外的配合
连接池只解决「连接复用」问题，治标不治本的情况要配合：
- 慢查询治理：一条 10s 的慢查询会占住连接池里的连接，把池子占满。
- 合理的隔离级别和事务范围：长事务长时间占用连接，等于池子变小。
- 只读连接走只读实例：把读写分离，减少主库连接压力。
小结
连接池参数没有「最优默认值」，只有「针对你的负载的最优值」。方法和压测优先，基于吞吐拐点定参数，同时治理慢查询和长事务，才能让连接池真正稳定运行。