Postgres 10连接池配置疑问：MaxPoolSize=20但Idle连接远超预期

你遇到的这个问题其实很常见，核心是客户端连接池的限制和数据库端连接统计的范围不匹配，下面我分几个关键点给你拆解：

1. 连接池是客户端进程级的限制，而非数据库全局限制 #

你连接字符串里的MaxPoolSize=20是客户端驱动（比如Npgsql这类.NET驱动）的连接池配置，它限制的是单个客户端进程内的最大连接数。如果你的应用是多实例部署、或者有多个工作进程（比如IIS应用池的多进程模式），每个进程都会维护自己独立的连接池，每个池都能开到20个连接。这样总连接数就会是进程数 × 20，很容易超过你预期的20，反映在数据库的pg_stat_activity里就是大量idle连接。

2. 你看到的idle连接可能包含非你的应用的连接 #

pg_stat_activity会列出数据库的所有连接，包括：

• 数据库自身的后台连接（比如autovacuum、wal writer等）
• 其他应用、工具的连接（比如pgAdmin、其他服务的postgres用户连接）
• 你的应用的连接

你需要过滤出仅属于你的应用的连接，才能准确验证连接池是否生效：

select state, count(1) 
from pg_stat_activity 
where usename='postgres' 
  and application_name='你的应用程序名称' -- 替换成你应用的实际名称
group by state;

这样就能排除无关连接的干扰，看到真实的应用连接数。

3. 连接未被正确归还到连接池 #

如果你的代码里没有规范地释放数据库连接（比如没使用using语句包裹连接，或者没有显式调用Close()/Dispose()），连接就不会被归还到客户端的连接池里。这时连接池会认为之前的连接还在使用，就会创建新的连接，导致数据库端的连接数不断累积，最终超过MaxPoolSize的限制。

4. ConnectionLifeTime的作用不是立即回收空闲连接 #

你设置的ConnectionLifeTime=15是指：当连接被归还到池里时，如果它的存活时间超过15秒，就会被销毁。但如果连接一直没被归还，或者归还时还没到15秒的阈值，它就会留在池里，同时数据库端的连接也会保持空闲状态，不会主动关闭。

排查步骤建议 #

• 先执行上面的过滤查询，确认你的应用实际占用的连接数是否超过20；
• 检查应用的部署架构：是否是多实例、多进程模式，计算总连接数的上限；
• 审计代码中的连接使用逻辑，确保所有连接都被正确释放；
• 验证客户端驱动是否真的启用了连接池（比如有些驱动可能需要额外配置，不过你已经设置了Pooling=true，大部分驱动会生效）。

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