max_connections 不是决定查询并发数的参数，而是 PostgreSQL 为每个客户端后端预留共享内存的预算。默认 100，范围 1–262,143。它决定：
- 允许的客户端后端数目；
- 预留的共享内存大小（每个后端占用 PGPROC、pg_stat_activity 行、锁表等）。
- 需要在主机重启后才能修改。
在 18.6 上，默认 shared_buffers 时，max_connections=100 时共享内存约 150 MB；1,000 时 197 MB；5,000 时 389 MB。锁表占用随连接数线性增长。热备机必须与主机使用相同或更大的 max_connections，否则启动失败或在 WAL 中警告。
连接成本
空闲后端仅占约 1 MB 私有内存；活跃后端会消耗 work_mem、hash join 内存等。超过核心数的活跃连接会导致上下文切换、锁竞争，吞吐量下降。
云服务默认值
- Heroku：500 → 5,000（Advanced tier）
- AWS RDS：公式LEAST(DBInstanceClassMemory/9531392, 5000)
- Azure：MIN(memoryGib*0.1049164697034809, 5000)
- Google Cloud SQL：16 GB 仅 500。
默认值已从 100 提升至 17–50 倍，取决于内存。建议使用 RDS Proxy 等连接池器来避免“too many clients”错误。
实践建议
1. 先在备机调高 max_connections，再在主机调高；反之则会导致恢复暂停。
2. 监控 pg_stat_activity、wait_event_type、load average，及时发现锁竞争。
3. 对高并发应用使用连接池，避免直接打开数百连接。
#开发者 #工具 #PostgreSQL #max_connections #云数据库 #RDSProxy
@DevToolboxHub