引言

从MySQL迁移到PostgreSQL（简称PG）的用户，最先遇到的问题是连接数管理。核心原因是两者底层架构存在本质差异，导致连接数管理逻辑不同。

一、核心差异：线程架构 vs 进程架构

1.1 架构对比表

特性 MySQL（线程架构） PostgreSQL（进程架构）
连接处理方式 基于线程（Threads），共享主进程内存空间 基于多进程（Processes），主进程（postmaster）通过fork创建独立后端进程（postgres）
资源开销 轻量级，上下文切换开销小 重量级，拥有独立内存空间，创建与调度开销大
连接数支持 可稳定支持上千连接，max_connections=2000可正常运行 默认可用连接数显著低于MySQL，高连接场景易出现异常
资源分配方式 线程共享主进程资源 每个连接对应独立进程，单独分配资源

1.2 关键结论

二、PG连接数问题的实际后果

2.1 主要影响

  1. 资源占用增加：每个连接对应独立进程，需额外占用内存、CPU等系统资源；
  2. 性能提前下降：进程数量上升后，操作系统调度压力增大，伴随内存交换频繁、进程间通信开销增加，导致PG性能快速下滑；
  3. 连接上限受限：若沿用MySQL的连接配置（如应用层连接池设置500-1000），PG会出现性能大幅下降甚至宕机。

2.2 配置建议

PG稳定运行无需高并发连接，维持几十到两三百个并发连接即可保障稳定性，核心在于提升连接利用率，不应直接将max_connections配置为几百上千。

三、解决方案：PGBouncer连接池

3.1 核心功能

PGBouncer是PG社区主流连接池工具，作为客户端与PG服务器的中间层：