当你把应用从直接连PostgreSQL切换到PgBouncer后，感觉世界都清净了。连接数稳定，数据库负载骤降。但用久了可能会发现，有些场景下事务行为变得有点“怪”：比如，一个会话里设置的临时变量，怎么跑到另一个请求里去了？或者，明明想长连接保持事务，怎么被强制断开了？
三种模式：不只是复用连接那么简单
这些问题，根源几乎都出在一个配置项上：pool_mode。PgBouncer提供了三种核心模式：Session、Transaction和Statement。它们的区别，远不止字面上理解的“会话级”或“事务级”复用。
- Session模式：这是最符合直觉的模式。一个客户端从连接到断开，期间PgBouncer会为其分配一个固定的后端数据库连接。这个连接一直被该客户端独占，直到客户端主动断开。听起来很完美，但它对连接复用的效率提升有限，主要解决了连接建立的开销，并未减少后端并发连接数。
- Transaction模式：这是PgBouncer的“王牌模式”，也是默认推荐。在这个模式下，一个后端数据库连接只在客户端事务期间被分配给它。事务一提交或回滚，这个连接就被立即放回池子，可以分配给下一个客户端。这意味着，一个客户端在事务之间的空闲期，根本不占用后端连接。复用率极高。
- Statement模式：这是最激进的模式。连接在每条SQL语句执行后就被回收。换句话说，即使你在一个事务块（BEGIN…COMMIT）内，每条语句也可能使用不同的后端连接。这带来了最高的连接复用率，但也彻底破坏了多语句事务的原子性，因为它要求自动提交（autocommit）。除非你非常清楚自己在做什么，否则基本不会用到它。
模式背后的“副作用”与陷阱
选择模式，其实是在选择一套行为契约。Transaction模式虽然高效，但它带来一个关键限制：客户端不能使用任何需要跨事务持久化的会话特性。这包括：
- 预备语句（Prepared Statements）
- 使用
SET命令设置的临时会话参数（如SET search_path TO ...） - 监听/通知（LISTEN/NOTIFY）
- 游标（Cursors）
因为下一次事务可能换一个后端连接，这些绑定在特定连接上的状态就丢失或错乱了。很多开发者踩的坑就在这里：应用在Session模式下跑得好好的，切换到Transaction模式后，一些依赖会话状态的代码就莫名其妙地出错。
“最适合”是一个权衡题
所以，回到那个核心问题：哪种模式最适合你的业务？这没有银弹，而是一道基于业务场景的选择题。
| 业务场景特征 | 推荐模式 | 核心理由 |
| 典型的Web应用，请求-响应式，事务短平快，无状态。 | Transaction | 最大化连接复用，用最少后端连接支撑最大并发请求。这是最常见的场景。 |
| 应用重度使用预备语句、临时表、或需要SET会话参数（如多租户的schema切换）。 | Session | 保证会话状态一致性，避免因连接切换导致的诡异错误。牺牲部分复用效率换取兼容性。 |
| 报表查询、ETL任务等需要运行长时间事务的操作。 | 考虑单独的服务或连接，或使用Session模式。 | 长事务会长时间独占池中连接，在Transaction模式下容易导致连接池耗尽，其他请求排队。 |
| 极致的连接复用需求，且业务逻辑能完全适配自动提交（每条语句独立）。 | Statement（罕见） | 理论上的最高性能，但对应用侵入性极强，风险高。 |
一个实用的策略是混合部署。你完全可以在同一个PgBouncer实例中，为不同的数据库或用户配置不同的池模式。比如，让主要OLTP业务走Transaction池，而为那个需要跑复杂报表的分析后台单独配置一个Session池。在pgbouncer.ini的[databases]部分，你可以这样配置：
oltp_db = host=... pool_mode=transaction
report_db = host=... pool_mode=session说到底，选择PgBouncer的模式，是在连接复用效率、应用兼容性和资源隔离之间找一个平衡点。理解你业务中SQL的真实行为模式，比盲目追求某个“最佳实践”数字要重要得多。有时候，为了省下那几十个连接，而引入难以排查的会话状态 bug，这笔账算下来可能并不划算。
这个配置坑我好久了，终于搞明白为啥事务里set变量失效了😅