4. PgBouncer 架构：三种模式与适用场景
PgBouncer 是 PostgreSQL 生态中最流行的轻量级连接池中间件。其核心架构围绕 三种工作模式 设计：Session（会话级）、Transaction（事务级） 和 Statement（语句级）。理解这三种模式的内部连接复用机制、资源开销和适用场景，是正确配置连接池参数的前提。
4.1 三种模式的核心架构对比
下图展示了 PgBouncer 在三种模式下，客户端连接与后端 PostgreSQL 连接之间的映射关系。箭头表示连接的生命周期绑定。
4.2 Session 模式（会话级）
工作机制： 客户端连接建立后，PgBouncer 立即从池中分配一个后端 PostgreSQL 连接，并在整个客户端会话期间保持独占。客户端断开后，连接才归还池中。
| 特性 | 说明 |
|---|---|
| 连接复用度 | 低（1:1 映射） |
| 资源开销 | 高（每个客户端占用一个后端连接） |
| 会话状态 | 完全保留（SET、临时表、预备语句等） |
| 适用场景 | 长连接、需要保持会话状态的应用程序（如管理工具、ORM 长会话） |
性能调优提示： Session 模式本质上只是连接复用，并未减少后端连接数。如果应用大量使用短连接，应优先考虑 Transaction 模式。
4.3 Transaction 模式（事务级）
工作机制： 客户端在事务开始时获取一个后端连接，事务提交或回滚后立即归还连接。下一个事务可能分配到不同的后端连接。这是 PgBouncer 最常用、最推荐的模式。
| 特性 | 说明 |
|---|---|
| 连接复用度 | 高（N: M 映射，M 通常远小于 N） |
| 资源开销 | 低（少量后端连接服务大量客户端） |
| 会话状态 | 不保留（事务结束后状态丢失） |
| 适用场景 | Web 应用、API 服务、OLTP 系统（短事务、高并发） |
核心优势： Transaction 模式能将后端连接数降低 10~100 倍。例如，1000 个 Web 请求只需 50~100 个 PostgreSQL 连接，大幅减少数据库进程上下文切换和锁竞争。
4.4 Statement 模式（语句级）
工作机制： 客户端每执行一条 SQL 语句，PgBouncer 就分配一个后端连接；语句执行完毕后立即归还。这是复用度最高的模式，但限制也最多。
| 特性 | 说明 |
|---|---|
| 连接复用度 | 极高（每条语句独立分配） |
| 资源开销 | 极低（连接使用时间最短） |
| 会话状态 | 不保留（语句结束后状态丢失） |
| 限制 | 不支持多语句事务、不支持预备语句、不支持临时表 |
| 适用场景 | 纯查询服务、无状态批处理、简单 INSERT 负载 |
使用限制： Statement 模式要求客户端不能依赖事务边界。如果应用使用
BEGIN / COMMIT 包裹多条语句，PgBouncer 会报错。生产环境极少使用此模式。
4.5 三种模式对比总结
| 对比维度 | Session 模式 | Transaction 模式 | Statement 模式 |
|---|---|---|---|
| 连接复用度 | 低 | 高 | 极高 |
| 后端连接数 | = 客户端数 | 远小于客户端数 | 远小于客户端数 |
| 会话状态保留 | 是 | 否 | 否 |
| 事务支持 | 完整 | 完整 | 不支持多语句事务 |
| 预备语句支持 | 是 | 是（需配置） | 否 |
| 典型延迟增加 | 极低 | 低 | 低 |
| 推荐度 | 特定场景 | ★★★★★ | 极少使用 |
4.6 模式选择决策流程
以下决策树帮助快速选择模式：
4.7 配置示例
在 pgbouncer.ini 中通过 pool_mode 参数指定模式：
[databases]
; 全局模式设置
pool_mode = transaction
; 为特定数据库覆盖模式
mydb = host=127.0.0.1 port=5432 dbname=mydb pool_mode=session
[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
default_pool_size = 25
max_client_conn = 500
最佳实践： 在
[databases] 段中为不同业务数据库指定不同模式。例如，管理后台使用 session，API 服务使用 transaction，实现精细化资源控制。