PostgreSQL默认采用进程模型处理客户端连接，每个新连接都会创建一个独立的后台进程，这种模式在连接数较少时运行稳定，但当应用并发量上升时，频繁的进程创建和销毁会消耗大量系统资源，甚至导致数据库服务不可用。因此合理优化应用连接模式是PostgreSQL性能调优的核心环节之一。
PostgreSQL原生连接机制解析
PostgreSQL的核心进程是主服务进程postgres，当有客户端发起连接请求时，主进程会fork出一个子进程专门处理该连接的所有操作，子进程的生命周期和连接保持一致。这种进程模型的优势是连接之间完全隔离，单个连接的异常不会影响其他连接，但劣势也很明显：每个进程都会占用独立的内存空间，默认情况下单个连接的后台进程会占用几MB到几十MB的内存，当连接数达到数百甚至上千时，内存消耗会急剧上升。
我们可以通过以下SQL查询当前数据库的连接状态：
-- 查询当前所有连接的详细信息
SELECT
pid,
usename,
application_name,
client_addr,
state,
now() - state_change AS state_duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid();
常见连接模式对比
目前PostgreSQL应用常用的连接模式主要分为三种，不同模式的适用场景差异较大，需要根据业务特性选择：
| 连接模式 | 实现方式 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| 直连模式 | 应用直接创建PostgreSQL连接 | 配置简单，无额外组件依赖 | 连接数不可控，高并发下资源消耗大 | 小型应用、测试环境、连接数极少的场景 |
| 连接池模式 | 应用侧或中间件侧维护连接池 | 复用连接减少创建开销，控制最大连接数 | 需要额外配置连接池参数，存在连接泄漏风险 | 中大型应用、常规并发业务场景 |
| 事务级连接模式 | 中间件仅在事务执行期间分配连接 | 连接利用率最高，支持极高并发 | 不支持长事务，部分特性兼容受限 | 高并发短事务业务，如电商订单、日志写入场景 |
连接模式优化实践
1. 合理配置PostgreSQL服务端参数
首先需要调整PostgreSQL自身的连接相关配置，避免服务端成为瓶颈。核心参数如下：
- max_connections：数据库允许的最大连接数，默认是100，需要根据服务器内存调整，一般建议设置为预期峰值连接数的1.2倍左右，不要盲目设置过大，否则会导致内存溢出。
- superuser_reserved_connections：为超级用户预留的连接数，默认是3，避免普通连接占满所有连接导致管理员无法登录数据库。
- idle_in_transaction_session_timeout：空闲事务的超时时间，默认是0表示不限制，建议设置为5-10分钟，自动回收长时间未提交的事务连接。
修改postgresql.conf后需要重启数据库生效，也可以通过以下SQL动态修改部分参数：
-- 动态修改空闲事务超时时间为5分钟（单位毫秒） ALTER SYSTEM SET idle_in_transaction_session_timeout = '300000'; -- 重新加载配置 SELECT pg_reload_conf();
2. 部署连接池中间件pgbouncer
pgbouncer是PostgreSQL官方推荐的连接池中间件，轻量高效，支持多种连接模式。以下是基础部署配置步骤：
首先安装pgbouncer，以CentOS为例：
yum install -y pgbouncer
然后编辑配置文件/etc/pgbouncer/pgbouncer.ini：
[databases] ; 配置需要代理的数据库，mydb是数据库名，host是PostgreSQL服务地址，port是端口 mydb = host=127.0.0.1 port=5432 dbname=mydb [pgbouncer] ; 监听地址和端口 listen_addr = 0.0.0.0 listen_port = 6432 ; 认证文件位置 auth_file = /etc/pgbouncer/userlist.txt ; 连接池模式，可选session/transaction/pool pool_mode = transaction ; 每个数据库的最大连接池大小 default_pool_size = 50 ; 最大客户端连接数 max_client_conn = 500 ; 日志配置 logfile = /var/log/pgbouncer/pgbouncer.log pidfile = /var/run/pgbouncer/pgbouncer.pid
配置完成后启动pgbouncer，应用侧只需要将连接地址改为pgbouncer的地址和端口即可，无需修改业务代码逻辑。
3. 应用侧连接池配置优化
如果选择应用侧连接池，以Java的HikariCP为例，合理的配置参数如下：
HikariConfig config = new HikariConfig();
// 数据库连接地址，指向pgbouncer或者直连PostgreSQL
config.setJdbcUrl("jdbc:postgresql://127.0.0.1:6432/mydb");
config.setUsername("db_user");
config.setPassword("db_password");
// 连接池最大大小，不要超过pgbouncer的default_pool_size
config.setMaximumPoolSize(40);
// 最小空闲连接数
config.setMinimumIdle(10);
// 连接超时时间，单位毫秒
config.setConnectionTimeout(30000);
// 连接最大存活时间
config.setMaxLifetime(1800000);
// 空闲连接超时时间
config.setIdleTimeout(600000);
HikariDataSource dataSource = new HikariDataSource(config);
4. 连接泄漏排查与处理
连接泄漏是常见的连接问题，指应用获取连接后没有正确关闭，导致连接一直被占用。可以通过以下SQL排查泄漏的连接：
-- 查询超过10分钟未变化的空闲连接
SELECT
pid,
usename,
application_name,
client_addr,
state,
query_start,
now() - query_start AS query_duration
FROM pg_stat_activity
WHERE state = 'idle'
AND now() - state_change > interval '10 minutes'
AND pid <> pg_backend_pid();
确认是泄漏连接后，可以使用以下命令终止对应连接：
-- 终止指定pid的连接，需要超级用户权限 SELECT pg_terminate_backend(12345); -- 12345是查询到的pid
优化效果验证
优化完成后，可以通过压测工具验证效果，比如使用pgbench进行并发测试：
-- 初始化测试数据，scale=10表示生成10倍默认大小的测试数据 pgbench -i -s 10 -h 127.0.0.1 -p 6432 -U db_user mydb -- 执行100个并发连接，每个连接执行1000次事务的压测 pgbench -c 100 -t 1000 -h 127.0.0.1 -p 6432 -U db_user mydb
对比优化前后的TPS（每秒事务数）和平均响应时间，通常合理的连接模式优化可以让TPS提升30%以上，同时大幅降低数据库服务器的内存和CPU消耗。
PostgreSQL连接模式连接池性能优化pgbouncer修改时间：2026-07-10 19:45:41