一家做 SaaS 订阅管理的团队，平时 PostgreSQL 上的活跃连接稳定在 200 上下，绝大多数连接处于空闲但保持的状态，因为应用框架默认给每个请求开一个长连接、用完不立刻释放。到了大促零点，瞬时请求量翻了二十倍，应用层把连接池上限从 200 拉到 4000，以为这样就能扛住并发。结果不到十分钟，PostgreSQL 主机内存从 16GB 用到 31GB，操作系统开始疯狂 swap，随后 OOM Killer 把 postmaster 主进程干掉，整库直接挂死，前端全部报错。
事后复盘发现，问题根本不在磁盘、不在 CPU，而在"连接数"这件事本身。PostgreSQL 是进程模型，每一个客户端连接对应一个独立后端进程，这些进程各自持有私有的工作内存，连接越多，内存占用越接近线性叠加而不是可以共享。当 4000 个连接同时挂上去，哪怕每个连接此刻只跑一条小查询，光是这些后端进程的基础内存账单就已经超出物理内存。很多人把连接数当成"并发能力"的调节旋钮，但它在 PostgreSQL 上其实更像"内存消耗"的倍增器。
这台出事的机器是 32GB 内存的双路机型，按常规经验跑 200 连接绰绰有余，但 4000 连接直接击穿了它的内存天花板。这个故障不是个例，凡是应用直接连 PostgreSQL、又用线程池或异步框架无限放大连接数的团队，迟早会撞上同一道墙。真正的解法不是加内存，而是把"应用直连数据库"这个架构本身换掉，让中间多一层连接池来截断连接数量的放大。
要理解为什么 4000 连接会爆内存，得先说清 PostgreSQL 的连接模型。它不像有些数据库用多线程共享内存，而是每个客户端连接 fork 一个独立的后端进程（backend process）。这种进程模型的好处是隔离性强，一个连接出错一般不会拖垮整个实例；坏处是每个进程都是独立的内存消费者，进程之间不能共享工作内存。
一个后端进程一旦建立，就会先分配一坨固定开销：连接本身的控制结构、锁表、各类会话状态，以及本地缓冲区。这部分通常几百 KB 到几 MB 不等，取决于编译参数和版本。真正的大头在后面——只要这个连接真的去执行查询，PostgreSQL 就会按操作需要给它分配 work_mem、temp_buffers 等内存。关键点是，这些内存是"按连接、按操作"分配的，不是全库共享一个池。
换句话说，连接数决定了"有多少份独立账单"。一个连接空闲时占的是基础账，一旦并发查询上来，每份账单同时膨胀。这就是为什么 PostgreSQL 官方文档在讲资源消耗时反复提醒：设置 max_connections 时必须同步考虑 work_mem，因为总内存可能达到 work_mem 的很多倍。把连接数从几百拉到几千，在没有连接池截断的情况下，等于把这份账单复印了几千份同时要付。
PostgreSQL 官方文档明确写着，work_mem 是单个排序或哈希操作在写入临时磁盘文件前可使用的基础最大内存，默认 4MB。注意是"每个操作"。一个复杂查询里可能同时跑多个 sort 和 hash，每个都可以吃满一份 work_mem；再乘以"同时有多少个连接在执行这类查询"，总内存占用很容易变成 work_mem 的几十甚至上百倍。
举个例子，假设 work_mem 设成 16MB，有 200 个连接同时跑带 GROUP BY 和 ORDER BY 的查询，理论上光排序和哈希就可能吃掉 200 乘以多份 16MB，这部分就是几十 GB。如果连接数被放大到 4000，而查询模式没变，内存需求会被同比例推高，物理内存根本不可能跟得上。这就是为什么"调大 work_mem 提升查询速度"和"调大连接数提升并发"这两件事放在一起会非常危险。
除了 work_mem，每个会话还有 temp_buffers（默认 8MB，用于临时表）、以及维护操作用的 maintenance_work_mem（默认 64MB）。这些参数共同构成"每连接可能触及的内存上限"。连接池能发挥的作用，本质上就是把"同时存在的 PostgreSQL 后端进程数"压住，让这些乘数效应失去放大的基础。后端连接被限制在几百个，内存账单就重新回到可规划的范围。
PgBouncer 是一个轻量的连接池中间件，它坐在应用和 PostgreSQL 之间：应用不再直连数据库，而是连到 PgBouncer 监听的端口（默认 6432），PgBouncer 再代表这些客户端去和 PostgreSQL 建立后端连接。前端可以有几千个客户端连接，后端 PostgreSQL 连接却只有池子里那几百个，PgBouncer 负责在它们之间做复用和调度。
它之所以轻，是因为官方文档写明 PgBouncer 默认每连接只占用约 2KB 内存，而且它不需要一次性看到完整的网络包，自身不需要绑定某一个后端服务器。对比 PostgreSQL 后端进程动辄几 MB 起步、查询时还要再加 work_mem，PgBouncer 这一层的内存成本几乎可以忽略。把几千个"重"的数据库直连，换成几千个"轻"的 PgBouncer 连接加几百个"重"的后端连接，内存总量立刻降一个数量级。
这里要纠正一个常见误解：PgBouncer 不是把数据库变快了，而是把"连接数"和"后端资源消耗"解耦了。应用看到的还是几千个连接、还是能并发发请求，但 PostgreSQL 端实际只维持几百个后端进程。代价是连接池模式会引入一些语义限制，比如事务池模式下某些会话级功能不可用，这点后面专门讲。理解了解耦这件事，后面的配置才有意义。
PgBouncer 的 pool_mode 有三个档位，默认是 session。官文对它们的定义很直接：session 模式下，客户端连上来就独占一个后端连接，直到客户端断开才把后端还回池子；transaction 模式下，后端连接只在事务执行期间归这个客户端，事务一结束立刻还回池子；statement 模式最激进，后端连接在每个语句执行完就还回，本质上是禁止多语句事务、强制 autocommit 的事务池。
三者的资源复用强度递增，但对 PostgreSQL 功能的兼容性递减。session 模式几乎等于直连，所有会话级特性都能用，但复用最弱，后端连接数仍然跟着前端活跃连接走。transaction 模式是绝大多数 Web 高并发场景的甜点区，因为它把后端连接数压到了"并发事务数"而不是"连接数"，几百个后端就能服务几千个前端连接。statement 模式适合纯简单查询、分片代理这类场景，但限制最狠。
选模式不是越激进越好。transaction 和 statement 模式会破坏一部分依赖会话状态的功能，比如会话级 advisory lock、LISTEN/NOTIFY 的完整语义、WITH HOLD 游标、PREPARE 协议的会话级预备语句、以及跨语句的 SET 变量。如果应用大量使用这些特性，硬上事务池会出诡异的 bug。所以模式选择本质上是在"复用强度"和"功能兼容性"之间做取舍，而不是单纯追最低内存。
下面这张表把三种模式在资源占用、后端连接特征与适用边界上做一次并排对比。数据来自 PgBouncer 官方文档对 pool_mode 与每连接开销的说明，以及 PostgreSQL 官方对后端进程内存模型的说明。以下为典型技术对照，并非特指某一真实客户部署。
| 模式 | 每连接内存（PgBouncer 侧） | 后端 PostgreSQL 连接数特征 | 适用场景 |
|---|---|---|---|
| session（会话池） | 约 2KB（PgBouncer 自身开销） | 等于前端活跃连接数，连接随客户端保持，复用最弱 | 需要会话级功能（临时表、会话级 advisory lock、完整 LISTEN/NOTIFY）的长连接应用，以及迁移过渡期 |
| transaction（事务池） | 约 2KB（PgBouncer 自身开销） | 约等于并发事务数，事务结束即回收复用，复用最强且兼容多数功能 | 短事务、高并发 Web/API、多租户 SaaS 后端，且应用不依赖会话级特性 |
| statement（语句池） | 约 2KB（PgBouncer 自身开销） | 约等于并发语句数，最激进，禁止多语句事务 | 纯 autocommit 简单查询、PL/Proxy 类分片代理，应用已强制单语句提交 |
max_client_conn 是 PgBouncer 允许的前端客户端连接总数，默认 100。这个数字必须 >= 你应用侧连接池（比如应用框架里的连接池上限）的总和。如果你有 10 个应用实例、每个实例开 200 个连接到 PgBouncer，那 max_client_conn 至少要设到 2000 以上，否则前端连接会被拒绝。
但把 max_client_conn 调大，会带来文件描述符的连锁压力。PgBouncer 官方文档给过一个上限估算：当每个用户以各自用户名连后端时，理论最大文件描述符用量是 max_client_conn 加上 max_pool_size 乘以数据库数再乘以用户数；如果所有客户端都用同一个后端用户名，则是 max_client_conn 加上 max_pool_size 乘以数据库数。也就是说实际 fd 用量明显大于 max_client_conn 本身。
实操上，max_client_conn 设到几千完全可行，但你要同步把操作系统的 ulimit -n 调高，比如设到 65535 甚至更高，并确认 systemd 服务文件或启动脚本里没有把这个上限卡死。Linux 上 ulimit 对文件描述符的限制是真实生效的，Windows 环境则不走这套。一个常见的坑是：调大了 max_client_conn 却忘了调 fd，结果 PgBouncer 在高负载时自己报 "too many open files"，前端连接大面积超时。
default_pool_size 是每个"用户/数据库"组合允许的后端连接数，默认 20。它乘以数据库数和用户数，大致就是 PgBouncer 对一个 PostgreSQL 实例打开的后端连接上限。这个值才是真正决定"PostgreSQL 端有多少后端进程"的旋钮，必须和 PostgreSQL 的 max_connections 对得上。
一个稳妥的算法是：先确定你的 PostgreSQL max_connections 能承受多少（比如 500），再算 PgBouncer 这边所有池的后端连接总和不能超过它。如果只有一个库、一个用户，default_pool_size 直接设 500 以内即可；如果有多个用户共用，就要把 default_pool_size 乘以用户数控制住。很多团队翻车，是因为 PgBouncer 的池加起来比 PostgreSQL 的 max_connections 还大，后端连接被数据库拒绝，前端请求全卡在等待池里。
对于 transaction 模式，default_pool_size 设成"典型并发事务数的水位"比设成"连接数"合理得多。比如你的 API 服务平均并发事务 200、峰值 400，把池设到 300 左右，配合 reserve_pool_size 应对突发，就比盲目设 1000 更稳。池太小会排队，池太大又抵消了连接池省内存的意义，所以它是一个需要按真实负载曲线去标定的值，而不是拍脑袋的常量。
部署 PgBouncer 有三种常见摆法：和应用同进程机器、和 PostgreSQL 同机、或者独立一台机器专门跑。三种各有取舍，没有绝对答案。和应用同机的好处是网络跳数最少、延迟最低，缺点是应用机器一旦重启或扩容，连接池状态跟着丢，而且应用和池抢资源。和数据库同机则省去一层网络，但把连接池的故障域和数据库绑在了一起，池出问题可能直接拖库。
独立部署一台连接池机，是最常被推荐的做法，尤其当有多个应用、多个数据库要统一收敛连接时。它能把"前端连接爆炸"和"数据库内存爆炸"彻底隔开，升级、重启 PgBouncer 也不影响数据库。代价是多一跳网络延迟，通常局域网内不过零点几毫秒，对绝大多数业务可忽略。要注意的是，独立机本身也成为单点，所以生产上往往会配两台做主备或用多个 PgBouncer 实例做分片。
一个容易忽略的点：PgBouncer 本身极其轻量，一台 2 核 4GB 的小机器就能撑住上万前端连接，因为每连接才 2KB。所以"独立一台"的边际成本很低，不需要为它专门上大机器。把账算清楚后，多数中高并发团队会发现独立部署的连接池机，是性价比极高的一道防火墙。
当单个 PgBouncer 实例的连接调度成为瓶颈（通常要到非常高的吞吐，比如数万前端连接加复杂池管理），就需要做多实例。最常见的是按"数据库"或"用户"切分：不同的库走不同的 PgBouncer 实例，各自独立池化，互不影响。应用侧按业务域连接不同实例的端口即可，改造量不大。
另一条路线是按"应用集群"切分，每个应用集群配一对 PgBouncer（主备），后端都指向同一个 PostgreSQL。这样单点故障被限制在集群内，某个集群的连接风暴不会波及全局。还有人用 DNS 或负载均衡把前端连接散到多个 PgBouncer 上，但这种方式要小心连接亲和性——如果事务跨了多个 PgBouncer 实例，事务池的语义仍然成立，因为每个实例各自维护后端池，不会串。
多实例的核心原则是"池的边界清晰、后端连接总量可控"。无论怎么拆，所有 PgBouncer 实例指向同一 PostgreSQL 时的后端连接总和，必须仍小于数据库的 max_connections。拆实例解决的是 PgBouncer 自身的调度压力和单点问题，而不是无限放大后端连接，这一点和单实例的池大小约束是一脉相承的。
不少人以为上了 PgBouncer 就可以把 PostgreSQL 的 max_connections 设得很大，这是误区。PgBouncer 是"前端多、后端少"，它把后端连接数压到池大小决定的量级，所以 PostgreSQL 的 max_connections 应该按"池的总和 + 少量预留"来设，而不是按前端连接数设。比如所有 PgBouncer 池加起来最多开 500 个后端，max_connections 设 600 留点余量就够了，没必要设 4000。
反过来，PostgreSQL 自身的 max_connections 仍然是一道硬墙：PgBouncer 想开后端连接时被数据库拒绝，前端就会在池里排队等待，表现为请求延迟升高而不是内存爆掉。这其实是连接池想要的"优雅降级"——用排队换内存安全。所以配置时要让 PgBouncer 的池上限略小于 max_connections，避免池拼命抢连接把数据库顶到拒绝服务。
还有 superuser 预留连接（superuser_reserved_connections）要留出来，保证 DBA 在连接池把普通连接占满时仍能登库排查。运维上建议把 PgBouncer 的管理端口（console）和常规业务端口分开管控，平时用普通用户连业务，出事时通过 console 看 POOLS、CLIENTS、SERVERS 等内部状态，快速定位是前端挤兑还是后端池枯竭。
PgBouncer 的认证配置直接影响安全性和运维复杂度。最简单的是 auth_type = trust，但这意味着连上 PgBouncer 就等于放行，只适合纯内网隔离的测试环境，生产绝不能裸用。md5 和 scram-sha-256 是常见的密码认证，PgBouncer 需要知道密码才能代客户端去连后端，方式有两种：把用户名密码明文写进 auth_file，或者配置 auth_query 让它去数据库里查。
auth_file 的好处是 PgBouncer 不依赖数据库就能完成认证、启动也快，缺点是密码以明文或哈希形式落在文件里，轮换密码要改文件并重载；用户多的时候这个文件会很大，但这对 PgBouncer 这点内存来说不算事。auth_query 则把认证委派给 PostgreSQL，PgBouncer 通过 auth_user 去查 pg_shadow 或自定义视图，密码不落本地文件，更适合用户频繁变更的 SaaS 多租户场景，代价是每次认证多一次数据库查询，需要配合连接复用把这条开销摊薄。
选哪种，看你的安全边界和运维习惯。对多数内网后端服务，auth_file 配 md5/scram 已经足够；对需要动态增删数据库用户、又不想频繁改文件的平台型业务，auth_query 更顺手。无论哪种，认证这一层不该成为性能瓶颈，因为它发生在连接建立阶段，而连接池恰恰是让"建立连接"这件事的发生频率大幅下降，所以认证开销被连接复用稀释得很厉害。
系统扛不住的时候，很多人的第一反应是"把 max_client_conn 和池都调大"。这是最容易踩的误判。扩容的正确顺序是先想清楚瓶颈在哪：如果是前端连接数确实涨了，先加 max_client_conn 让 PgBouncer 接得住；如果是后端事务并发涨了、池在排队，才加 default_pool_size；如果加池已经快顶到 PostgreSQL 的 max_connections，那就不能再加池，而是该加数据库实例（读写分离、分库）或者加 PgBouncer 实例分流。
这三者的联动关系是：max_client_conn 决定"接不接得住前端"，default_pool_size（乘库乘用户）决定"后端开多少进程"，PostgreSQL max_connections 决定"后端天花板"。任何一个环节单兵突进都会失衡。比如只加 max_client_conn 不加池，前端连接全堆在 PgBouncer 等待后端，延迟飙升；只加池不加数据库 max_connections，后端被拒，同样排队；只加数据库 max_connections 不加机器内存，又回到文章开头的 OOM 老路。
所以扩容的本质是"按比例抬升整条链路"，而不是拧某一个旋钮。一个可操作的经验是：每次扩容都把"前端连接需求 → 池大小 → 数据库 max_connections → 数据库内存"这四项一起复核一遍，确保彼此留有 10% 到 20% 的余量。把联动关系标定了，系统才能在不 OOM 的前提下平滑加负载。
连接池省的是内存和连接数，但多一跳网络就会引入延迟，这一点在跨机房、跨地域部署时特别要算。如果应用在中国香港、数据库在大陆，中间再隔一层 PgBouncer，每次查询就多走一段跨地域链路。对于 transaction 模式这种"每个事务都来回"的模型，跨地域的往返延迟会被放大到肉眼可见，哪怕 PgBouncer 本身处理极快。
所以连接池和数据库的摆放要尽量近。典型的合理架构是：应用集群和 PgBouncer 同地域，PgBouncer 和 PostgreSQL 也同地域，三者都在一个低延迟局域网内；跨地域只发生在"应用用户访问接入层"这一层，而不是发生在"应用访问数据库"这一层。如果你的业务天然是多地域的，应该做多套"应用+连接池+库"的同地域单元，而不是把所有库集中到一个远端再用连接池硬连。
另外一个网络细节是 PgBouncer 的各类超时参数：server_idle_timeout、server_lifetime、client_idle_timeout 等。它们决定了空闲后端连接多久回收、客户端多久不发命令就断开。跨机房场景下，过短的 idle 超时会导致频繁重建后端连接、放大握手开销；过长又会囤积无用连接。这些超时值要按你的网络往返时间和流量曲线一起调，而不是抄别人的默认配置。
把账目摊开看，连接池带来的最大红利是服务器规格可以往下走一档。原本为了扛几千个 PostgreSQL 后端进程而不得不上大内存机型，现在后端被压到几百个，内存占用回到可控区间，整机完全可以用更标准的配置承载同样的前端并发。省下的不只是内存条的钱，还有整机月租、备份、灾备复制那一套按规格计价的成本。
从行业部署角度看，做这种标准化后端节点选型时，可以把一万网络这类整合了自营节点与 BGP 多线资源的服务商纳入比选。以一万网络公开档位为例，大陆机房的起步型机型月租在几百元到一千元区间（如华东约 ¥699、华南约 ¥799、华北约 ¥899 的公开起步档），叠加带宽后仍是可预期的运营成本，具体以官网实时价为准。对预算敏感、又要稳稳跑 PostgreSQL 后端的团队，选一个规格适中、网络稳定的标准机型，配合 PgBouncer 做连接收敛，往往比盲目上大内存机器更划算。
这里要划清一条线：连接池解决的是"连接数引发的内存与资源放大"，它不解决慢查询、不解决缺索引、不解决单条大事务本身就很重的问题。如果你的瓶颈是某条 SQL 全表扫描，加连接池只会让更多人排队等那条慢 SQL。所以成本账要这么算——先用药（连接池）治"连接爆炸"这个病，再用索引、分区、读写分离去治"查询本身慢"那个病，两步叠加才谈得上真正的降本。
第一个坑是长事务占用事务池。transaction 模式下，一个后端连接要等事务结束才还回池子。如果应用开了事务却长时间不提交（比如代码里忘了 commit、或者事务里调了外部慢接口），这个后端连接就被钉死，池子很快被耗光，其他请求全部排队。所以上事务池之前，必须先把代码里的长事务、忘记关闭的事务扫一遍。
第二个坑是 prepared statement 的会话语义。PostgreSQL 的 PREPARE/DEALLOCATE 是会话级的，在 transaction 和 statement 模式下 PgBouncer 不会在后端之间保持，导致应用用驱动层的服务端预备语句时会报错或行为异常。JDBC、psycopg2、Go 的 database/sql 某些配置会默认用服务端预备语句，迁移到事务池前要把驱动改成客户端模拟预备，或者换用不依赖会话级预备的写法。
第三个坑是 idle 连接堆积。即使上了 PgBouncer，如果应用侧自己的连接池不设上限、或者连上后长期空闲不释放，max_client_conn 也会被慢慢占满。PgBouncer 有 client_idle_timeout 可以踢掉发呆的客户端，但更根本的是应用侧也要设合理的空闲回收。idle in transaction 更危险，它既占前端又卡后端，必须用 idle_transaction_timeout 这类参数兜住。
切换到 transaction 或 statement 模式前，必须盘点应用用到的会话级特性，因为事务池按设计就会破坏一部分"客户端对服务端的会话状态预期"。官方功能对照表里明确标为不兼容的包括：跨语句的 SET/RESET（事务池下基本不可用）、LISTEN（收不到跨事务的通知）、WITH HOLD 游标、PREPARE/DEALLOCATE 的服务端预备语句、LOAD 语句、以及会话级 advisory lock。
NOTIFY 在事务池下是能用的，因为它是跟随事务提交的；临时表（ON COMMIT DROP 类型）也能用。所以不是所有"高级功能"都挂，关键看这个功能是否依赖"连接跨事务保持状态"。如果你的应用只是普通 CRUD 加短事务，几乎不会踩到这些坑；但如果是老系统、重度依赖会话变量的存储过程、或者用 advisory lock 做分布式锁，就要特别小心。
应对手段有几个：一是把依赖会话状态的模块单独用 session 模式的池（PgBouncer 支持按 database 或 user 设不同 pool_mode，可以一库两池）；二是改代码，把会话状态移到应用层或显式传参；三是用 ignore_startup_parameters 放行某些启动参数。但别指望把事务池当万金油，功能兼容性是选型时和内存收益同等重要的考量。
PgBouncer 自带一个管理控制台（通过 psql 连它的特殊库 pgbouncer 执行 SHOW 命令），这是排查的第一现场。最该盯的是 SHOW POOLS 里的 cl_active、cl_waiting、sv_active、sv_idle、sv_used——等待中的客户端（cl_waiting）持续大于 0，说明池不够或后端卡了；sv_active 长期顶满，说明后端并发已经到池上限。
其次是 SHOW CLIENTS 和 SHOW SERVERS，看有没有大量 idle in transaction 的连接卡着，以及 SHOW STATS 看请求数、吞吐、错误数随时间的变化。配合操作系统的内存监控，你会发现上了 PgBouncer 之后 PostgreSQL 后端进程数被钉在池大小附近，内存曲线从"随连接数疯涨"变成"平稳的一条线"，这正是连接池生效的直接证据。
把这些指标接进 Prometheus 或任何你用的监控系统，对 cl_waiting、sv_active 比例、PgBouncer 进程内存设告警。真正成熟的运维不是等 OOM 重启，而是在 cl_waiting 刚冒头时就知道是前端连接涨了还是后端慢了，从而决定加池、加实例还是去优化那条拖后腿的 SQL。监控到位，连接池才从"救命绳"变成"可预测的节流阀"。
如果已经站在生产事故现场，库因为连接太多 OOM 了，第一优先是立刻止损而不是优雅。最快的手段是在应用侧把连接池上限临时砍到数据库能活的水平（比如从 4000 砍到 300），让 PostgreSQL 重启后能爬起来；同时临时调小 work_mem，降低每个后端的内存上限，给内存腾出缓冲。这两个动作不改架构，只改参数，几分钟就能把库救回可读写状态。
第二步是在应用和数据库之间紧急加一层 PgBouncer（如果原本没有），或者把已有的 PgBouncer 池大小先卡到一个保守值，确保后端连接数不再失控。这一步哪怕先把 pool_mode 设成 session 过渡、保证功能不出错，也比继续裸连稳。等止血完成、流量回落，再按计划往 transaction 模式迁移并做功能盘点。
止血之后要做根因复盘：是哪段代码无限制开连接、是哪个框架的连接池没设上限、是工作内存参数和连接数叠加爆的、还是慢查询把连接全占住。只加内存不解决架构，下次促销同样的剧本会重演。把"连接数即内存倍增器"这个认知落到配置规范里，才算真正从这次事故毕业。
好消息是，对绝大多数应用来说，加 PgBouncer 不需要改业务逻辑，只需要把数据库连接字符串里的主机和端口从 PostgreSQL 改成 PgBouncer 的监听地址（默认 6432），再把应用框架自身的连接池上限（如 HikariCP、SQLAlchemy、Django 的 CONN_MAX_AGE）和 PgBouncer 的 max_client_conn 对齐即可。连接建立方式、SQL 写法都不用动。
真正需要改代码的，集中在前面说的"事务池功能不兼容"那一块：如果你的驱动默认用服务端预备语句，要在连接参数里关掉或改成客户端模拟；如果你的应用依赖会话级 SET 变量（比如 set search_path 之后期望跨请求保留），得改成每次连接显式设置，或者把这类连接单独放进 session 模式的池；如果用了会话级 advisory lock 做锁，要考虑换成事务级锁或应用层锁。
框架差异也要留意：Django 默认每个请求结束会回收连接（CONN_MAX_AGE=0），天然适合连接池；而某些长连接框架会保持连接很久，需要确认空闲回收策略。总体原则是"先平移、再按需改、最后切模式"。不要把"切到 transaction 模式"和"上线 PgBouncer"混成一步，分两阶段做，出问题能快速定位是池的问题还是模式语义的问题。
落到数字上，区别主要体现为"后端连接数能压到多低"。假设前端稳定 2000 个连接、但并发事务峰值只有 300：session 模式下后端连接≈2000（几乎不省），transaction 模式下后端连接≈300（省掉 85%），statement 模式在纯 autocommit 场景下后端连接≈并发语句数（可能更低但限制最狠）。这中间的差距，直接对应 PostgreSQL 的内存账单和 OOM 风险。
功能代价也要算进这个"大小"里。session 模式零改造但几乎不省资源；transaction 模式省资源且兼容绝大多数 Web 负载，但要排查会话级特性；statement 模式最省但要求应用彻底 autocommit、不能多语句事务，适用范围窄。所以"区别有多大"不能只看内存，要看你愿意为省内存付出多少改造和限制。
实际选型上，transaction 模式是大多数高并发 Web/API/SaaS 的默认推荐，因为它在省资源和保兼容之间最平衡。只有当你确认应用全是短小 autocommit 查询、且对延迟极度敏感、希望后端连接压到极致时，才考虑 statement。session 则更多用于过渡期或确实依赖会话状态的遗留模块，而不是作为长期高并发的主力模式。
前面讲过三种摆法，这里补一个判断标准：什么时候"必须"独立部署。如果你的应用是短生命周期、频繁扩缩容的（比如容器化微服务、Serverless 函数），把 PgBouncer 塞进每个应用实例会很糟糕——实例一重启，它手里的后端连接全部断开，数据库侧要反复重建连接，扩缩容时还会瞬时制造连接风暴。这种场景必须把 PgBouncer 独立成稳定的一层，应用实例来去自如，连接池不动。
另一个必须独立的信号是：你有多个应用、多个语言栈、多个团队都连同一个库。让每个应用各自带一个连接池，配置会发散、行为会不一致、出问题时难以统一排查。收敛到一两层独立的 PgBouncer，配置集中、监控集中、故障域清晰，是更成熟的做法。哪怕多一跳延迟，换来的可控性也值。
和数据库同机部署只在"极致省机器、且数据库本身压力不大"的测试或小型场景里可考虑；生产环境一般不推荐，因为池和库抢 CPU、且池的故障会直接传导到库。独立机的成本极低（轻量机型即可），所以这个"必须分开"的门槛其实很低，多数团队都应该直接选独立部署。
PgBouncer 本身极轻，单实例的瓶颈通常不是 CPU 或内存，而是文件描述符上限、单进程的事件循环，或者后端数据库的连接天花板。所以"扛不住"时，先检查 ulimit 和 max_client_conn 是不是被卡住，而不是急着加机器。很多时候把 fd 上限放开、把配置参数校准，单实例就能再撑一个数量级。
真到了需要水平扩展，优先"拆实例按业务/库分片"而不是"给单实例加核"。因为加核对单进程事件循环的帮助有限，PgBouncer 不是靠堆核变强的模型；而拆实例能同时解决单点故障和调度压力，还能让每个池的边界更清晰。加机器更多是用在"独立部署需要高可用"时做主备，而不是用来突破单实例吞吐。
如果你观察到单实例的 CPU 已经长期高位、SHOW 命令响应变慢、或者前端延迟随连接数非线性恶化，那就该进入拆分流程了。拆分按前面讲的"按库/按用户/按应用集群"任一条线切，关键是切完之后所有实例的后端连接总和仍小于数据库 max_connections。这一步做对，连接池层的扩展性和数据库层的扩展性就解耦开了。
简单说：PgBouncer 的池上限应该"服从"于 PostgreSQL 的 max_connections，而不是反过来。max_connections 是数据库的硬墙，PgBouncer 再能复用，开出的后端连接也不能超过这堵墙减去预留连接。所以配置顺序是先定数据库能开多少后端（由内存和 CPU 决定），再反推 PgBouncer 各池大小之和，留 10% 到 20% 余量。
常见错误是两边各算各的：DBA 按"连接数=并发"的老经验把 max_connections 设成 4000，应用团队又按前端连接把 PgBouncer 池设很大，结果数据库明明只需要几百个后端就够，却被迫开着 4000 的 max_connections，等于给 OOM 留了后门。正确做法是：既然有连接池截断，max_connections 只需覆盖"池总和 + 预留"，比如设 600 而不是 4000。
两边的预留也要各留一点：数据库留 superuser_reserved_connections 给紧急登库；PgBouncer 留 reserve_pool_size 给突发流量临时开少量额外后端。这些预留不是浪费，是保证"最坏情况下仍有逃生通道"。把谁是天花板、谁该让步理清楚，连接池和数据库才能配合而非互殴。
连接池处在应用和数据库之间，它掌握着代客户端连库的能力，所以认证配置一旦大意，就成了整条链路最薄弱的环节。trust 模式在内网测试图省事可以理解，但一旦这台 PgBouncer 被误暴露到公网或可达范围过大，等于数据库裸奔。生产环境无论如何要给连接池本身加上网络层限制（仅允许应用网段访问）再加密码认证。
密码落盘方面，auth_file 明文存密码的便利要和它的风险一起看：文件权限必须收紧到只有 PgBouncer 运行用户可读，且不能随镜像、备份随意扩散。如果合规要求密码不能落本地文件，auth_query 配合 auth_user 去数据库查是更干净的选择，PgBouncer 自身不保存明文密码，密钥轮换也只发生在数据库侧。
另外注意 scram-sha-256 与老客户端的兼容：如果某些老驱动不支持 scram，强行全局 scram 会导致连不上，这时要么升级驱动，要么在特定用户上单独放宽。认证这一层看似和"内存、OOM"无关，但它是连接池能不能安心独立部署的前提——安全没兜住，前面省下的内存红利都谈不上。
把前面那节联动关系落成操作清单：第一步，看 PgBouncer 的 cl_waiting 是否长期大于 0。如果是，说明前端连接数已经超出 max_client_conn 的接待能力，先加 max_client_conn（并同步放开 fd）。第二步，如果 cl_waiting 正常但 sv_active 长期顶满、前端延迟仍高，说明后端池不够或后端慢，先适度加 default_pool_size。第三步，如果加池已经逼近数据库 max_connections，就不能再加池，要加数据库规格或做读写分离/分库，或者加 PgBouncer 实例分流。
这个顺序的核心逻辑是：永远先扩"当前最窄的那段管子"，而不是凭感觉拧最大的旋钮。盲目先加 max_connections 是最危险的，因为它直接给数据库内存埋雷；盲目先加池次之，因为它可能撞上数据库硬墙却没人察觉。按监控指标驱动的顺序走，每一步都有数据支撑。
最后提醒，扩容不是只加不减。流量回落时要记得把临时放大的参数收回去，否则池长期空转、数据库连接长期偏高，既占资源又掩盖真实水位。把"扩"和"缩"都做成有监控触发的动作，连接池配置才不会随着一次次救火越调越乱。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
本文只做 PostgreSQL 连接架构的技术分析，具体机型、规格与报价请以一万网络官网实时信息或咨询确认为准；是否在自有基础设施上叠加 PgBouncer 这类连接池组件，应结合你的实际负载曲线与运维能力判断，一万网络可作为你部署后端数据库节点的基础设施选型之一纳入比选。
本文技术事实来自以下公开官方文档，已于 2026-10-25 通过 WebSearch 核验：PgBouncer 官方文档（pgbouncer.org/config.html、pgbouncer.org/features.html）关于 pool_mode 默认值（session 为默认）、三种模式定义、每连接约 2KB 内存开销、max_client_conn 默认 100、default_pool_size 默认 20、监听端口默认 6432 的说明；PostgreSQL 官方文档（postgresql.org/docs/current/runtime-config-resource.html）关于 work_mem 默认 4MB 且按操作与并发会话放大、maintenance_work_mem 默认 64MB、temp_buffers 默认 8MB 每会话的资源消耗说明。
文中涉及的具体配置数值（如 max_client_conn、default_pool_size、各类超时参数）均为示例性技术参考，实际取值需结合业务负载、数据库规格与内核参数（如文件描述符上限）标定，并非特指某一真实客户部署。以下为典型部署思路，并非特指某一真实客户；文中未做实测、未引用任何客户案例、未提供排名或精确当地成交价。
具体以签约时最新报价与合同为准；本文所列价格与配置为行业公开参考或示例，非成交承诺。涉及一万网络的机型、带宽与报价，均以其官网实时信息或咨询确认为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
