PostgreSQL数据库连接创建逻辑及空闲连接问题咨询

你观测到的多出来的空闲连接，90%以上概率是后端数据库驱动/ORM层的连接池机制默认配置导致的，不属于业务逻辑异常。

为什么限制max_connections=1依然能正常处理请求 #

• 你压测的请求负载远未达到单连接的处理上限：常规短事务、简单CRUD类的OLTP请求，PostgreSQL单连接每秒可处理数千次请求，只要压测过程中没有慢查询、长事务长期占用连接，单连接完全可以承载你模拟的请求量级，那些处于idle状态的连接本身就没有参与实际请求处理。
• 连接池的备用连接本身就不会全程参与工作：只有并发请求数超过当前活跃连接数的时候，连接池才会调度空闲连接顶上，你压测的并发度不够的话，备用连接全程只会保持空闲状态。

多余空闲连接的来源 #

• 核心来源是多进程/多线程部署下的独立连接池：几乎所有主流后端数据库驱动、ORM框架都会默认开启连接池，且会预设最小空闲连接数。如果你的服务是多worker部署（比如Python Gunicorn多进程、Node.js cluster模式、Java Web容器多线程、Go服务多协程池配套独立连接），每个工作进程/线程都会维护自己的独立连接池，总连接数为单池连接数乘以工作进程数，很容易达到你观测到的20-40个规模。
• 少数特殊逻辑会创建额外独立连接：比如驱动的连接健康探活临时连接、ORM框架做表结构元数据查询的专用连接、如果业务用到了LISTEN/NOTIFY消息监听、逻辑复制等功能，也会创建独立长连接，但这类连接占比极低，一般不会超过3个。

这些空闲连接的实际作用 #

• 降低突发流量的响应延迟：预创建的空闲连接已经完成了TCP握手、数据库身份认证、会话参数初始化流程，突发请求进来可以直接使用，省去了新建连接几十到上百毫秒的开销。
• 避免频繁建连打满数据库资源：PostgreSQL新建连接的成本很高，每个连接会占用5-10MB左右的内存，还要走权限校验、系统目录加载流程，高并发下频繁建连断连会大量消耗数据库CPU，连接池保活一定数量的空闲连接就是为了复用连接，降低这部分开销。
• 预留资源应对异常场景：如果业务中偶尔出现慢查询、长事务占用工作连接，备用空闲连接可以承接其他正常短请求，避免所有请求排队阻塞。

生产环境不建议直接把数据库连接数限制为1，一旦唯一的连接被慢查询、长事务占用，所有后续请求都会直接排队超时，引发业务故障。一般建议业务侧总连接池大小控制在数据库CPU核数*2的量级即可，不需要盲目开大量连接，也不要过度压缩连接数。

内容的提问来源于stack exchange，提问作者AlexandrT