1. 连接池基础概念
1.1 什么是数据库连接池
数据库连接池（Connection Pool）是一组预先创建并保持打开的数据库连接的集合。应用程序不再直接向数据库发起连接请求，而是从连接池中“借用”一个已有连接，使用完毕后再“归还”给池，供其他请求复用。
在 PostgreSQL 中，每个后端进程对应一个独立的数据库连接。频繁创建和销毁连接会带来显著的 CPU、内存和网络开销。连接池的核心作用就是消除这种重复开销，让有限的连接资源被高效复用。
核心思想： 连接池将“连接创建”与“连接使用”解耦，由池管理器统一管理连接的创建、分配、回收和销毁。
1.2 为什么需要连接池
PostgreSQL 采用“每个连接一个进程”的架构。每次建立新连接，数据库都需要 fork 一个后端进程，执行认证、权限检查、内存分配等操作。在高并发场景下，这种开销会急剧放大。
| 问题 | 说明 | 影响 |
|---|---|---|
| 连接创建开销高 | TCP 三次握手 + PostgreSQL 认证握手 + 后端进程 fork | 每次连接耗时 1~10ms，高并发下累积明显 |
| 内存占用大 | 每个 PostgreSQL 后端进程占用约 5~10 MB 内存 | 1000 个连接可能消耗 5~10 GB 内存 |
| 连接数上限受限 | max_connections 参数受系统资源限制 | 超出后新连接被拒绝，应用报错 |
| 上下文切换频繁 | 大量空闲连接仍占用进程调度资源 | CPU 利用率下降，吞吐量降低 |
| 连接泄漏风险 | 应用异常退出时连接未正确关闭 | 数据库连接数持续增长，最终耗尽 |
性能陷阱： 在 PostgreSQL 中，
max_connections 设置过高（如超过 500）反而会降低整体吞吐量。因为 CPU 时间被大量空闲进程的调度和锁竞争消耗。连接池正是解决这一矛盾的关键手段。
1.3 连接池 vs 直连：性能对比
下面从多个维度对比“应用直连 PostgreSQL”与“通过连接池访问”的性能差异。
| 对比维度 | 直连模式 | 连接池模式 | 性能差异 |
|---|---|---|---|
| 连接建立时间 | 每次请求都经历完整建连过程 | 仅首次建连，后续复用 | 直连耗时高 10~50 倍 |
| 数据库连接数 | 等于并发请求数 | 固定为池大小（如 20~50） | 直连连接数高 10~100 倍 |
| 内存占用 | 随并发线性增长 | 稳定在池大小 × 单连接内存 | 直连内存高 5~20 倍 |
| 请求延迟（P99） | 建连延迟 + 查询延迟 | 仅查询延迟（池内等待可忽略） | 直连 P99 高 2~5 倍 |
| 系统吞吐量（TPS） | 受连接数上限和上下文切换限制 | 连接数可控，CPU 利用率更高 | 连接池 TPS 高 2~10 倍 |
| 抗突发能力 | 突发流量导致连接数暴涨，可能 OOM | 请求排队，连接数不变 | 连接池更稳定 |
1.4 连接池的核心价值总结
- 资源复用： 复用 TCP 连接和 PostgreSQL 后端进程，消除重复建连开销。
- 连接数控制： 将数据库连接数限制在可控范围内，避免连接风暴。
- 请求排队： 当所有连接被占用时，新请求在池外排队等待，不会压垮数据库。
- 连接健康检查： 自动检测并剔除失效连接，保证应用获取的连接可用。
- 性能稳定： 消除建连延迟抖动，P99 延迟更可预测。