PgBouncer高并发优化需分五步：一选对池模式（transaction/session/statement）；二动态调优连接数（default_pool_size、reserve_pool_size等）；三设分级超时（server_idle_timeout、idle_transaction_timeout等）；四启用复用机制（用户映射、DISCARD ALL、round-robin）；五强化监控（SHOW POOLS/LISTS、pg_stat_activity诊断）。
如果您在高并发场景下遭遇PostgreSQL连接耗尽、响应延迟升高或事务超时频发，则很可能是连接池配置未能匹配实际负载特征。以下是针对PgBouncer在高并发环境中的多维度优化实践：
一、选择合适的连接池模式
PgBouncer支持三种池化模式，其资源复用粒度与应用事务行为强相关。生产环境中必须根据SQL执行模型匹配对应模式，否则将引发连接泄漏、事务隔离异常或prepared statement失效等问题。
1、确认应用是否使用显式BEGIN/COMMIT事务块：若绝大多数操作为短事务（如单条INSERT+COMMIT），推荐启用transaction模式。
2、检查是否存在长会话状态依赖（如临时表、会话级变量SET LOCAL）：若存在，必须使用session模式，否则将导致状态污染。
3、验证是否禁用多语句事务（如所有DML均以autocommit方式执行）：仅在此前提下，可考虑statement模式，但该模式不兼容任何含BEGIN的SQL。
二、动态调优连接数参数
静态设置default_pool_size易导致资源闲置或争抢。应依据数据库max_connections上限、CPU核心数及典型并发请求分布进行分层配置，避免全局统一值造成瓶颈转移。
1、计算基础池大小：将PostgreSQL的max_connections值乘以0.6，结果向下取整作为default_pool_size初始值。
2、为关键业务库单独配置：在[database]段中为高优先级数据库（如orders、payments）显式声明pool_size，值设为default_pool_size的1.5倍。
3、启用应急缓冲：设置reserve_pool_size为default_pool_size的20%，确保突发流量下仍有连接可用，该值不可超过max_client_conn的10%。
三、精细化超时策略配置
默认超时参数适用于通用场景，但在高并发短连接密集型服务中，过长的空闲等待会阻塞连接释放，而过短则引发频繁重连。需结合应用链路RTT与事务平均耗时设定分级阈值。
1、缩短server_idle_timeout：设为30秒，强制回收超过半分钟无活动的后端连接，防止数据库侧堆积无效进程。
2、严控idle_transaction_timeout：设为45秒，此值必须小于应用层事务超时设置至少10秒，避免PgBouncer提前中断未提交事务。
3、限制查询排队时长：将query_wait_timeout设为90秒，使客户端在连接池满载时快速失败而非无限等待，便于上层实现熔断降级。
四、启用连接复用增强机制
PgBouncer默认对每个user@database组合建立独立连接池，但在微服务架构中，大量服务共用同一数据库用户会导致池间资源割裂。通过用户映射与连接复用策略可提升整体利用率。
1、在[users]段添加通配符映射：配置"postgres = auth_user=pgbouncer_auth"，使所有应用连接复用同一认证用户后端连接。
2、启用server_reset_query：在[pgbouncer]段设置server_reset_query = "DISCARD ALL"，确保每次连接归还前清除临时对象与会话设置。
3、配置自动重连：添加server_round_robin = 1，当某后端节点不可达时，自动将请求路由至其他健康节点，无需重启PgBouncer进程。
五、运行时监控与连接诊断
高并发下连接池状态瞬息万变，仅依赖静态配置无法及时发现资源倾斜或连接泄漏。必须通过内置命令与指标联动定位根因。
1、实时查看连接分布：执行SHOW POOLS;命令，重点观察cl_waiting列是否持续大于0，该值非零表明客户端请求正在排队。
2、识别长事务持有者：执行SHOW LISTS;并结合SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction';定位未及时提交的会话。
3、验证连接复用效果：对比pgbench压测前后pg_stat_activity中backend_type为client backend的数量变化，启用PgBouncer后该数值应稳定在pool_size范围内。
