GKE集群中Npgsql搭配PgBouncer访问Cloud SQL Postgres高延迟咨询

一、现有Npgsql配置的缺失项 #

• 未开启Npgsql内置的自动预编译语句缓存：默认配置下Npgsql不会自动缓存重复的查询执行计划，结合EF Core生成查询的CPU开销，是你压测时Pod CPU接近100%的核心原因。
• 连接池参数未做全链路匹配：为适配PgBouncer直接设置Pooling=false的逻辑完全错误——等于同时丢掉了应用侧连接复用、PgBouncer侧连接收敛两层优化能力，既没有减少应用侧的建连开销，又触发了PgBouncer的会话状态清空机制。
• 缺少连接生命周期的管控参数：未配置连接闲置回收、修剪规则，长期运行下会积累大量无效空闲连接，额外占用CPU与数据库侧资源。

二、每次查询触发parse/bind流程的原因 #

• 所有查询均使用<unnamed>匿名语句执行：未采用带命名的预编译模式，PostgreSQL每收到一条匿名查询，就必须完整走一遍语法解析、执行计划生成、参数绑定的全流程，没有任何缓存可以复用。
• PgBouncer默认工作模式强制清空会话状态：你日志中出现的DISCARD ALL语句就是PgBouncer在事务结束后自动执行的清理逻辑，会把当前连接上缓存的所有预编译语句、会话配置全部清空，下一次请求拿到连接时，不管之前做过多少次查询，都得重新走完整的parse/bind流程。
• 你对日志耗时的解读存在偏差：日志明确记录parse耗时0.112ms、bind耗时0.144ms，两步加起来才0.256ms，根本不存在你感知的256ms级解析开销。你观测到的589ms间隔、整体压测的秒级延迟，全来自连接新建、TLS握手、PG认证、PgBouncer连接排队的开销，和查询本身的执行速度无关。

三、可直接落地的修复调整 #

• 恢复Npgsql侧的连接池配置：将Pooling改回true，不要关闭客户端侧的连接复用能力，PgBouncer仅作为数据库侧的连接收敛层存在，不需要承担客户端的连接管理职责。
• 开启Npgsql的自动预编译能力：在连接串中增加Max Auto Prepare=20;Auto Prepare Min Usages=1参数，让Npgsql自动缓存重复的LogIn查询的执行计划，直接消除重复parse/bind的开销，同时降低客户端CPU占用。
• 调整PgBouncer工作模式：将默认的transaction模式改为session模式，确保连接上的会话状态（包括预编译语句缓存）不会被事务边界打断、清理。
• 补充连接生命周期管控参数：在连接串中增加Connection Idle Lifetime=300;Connection Pruning Interval=30，定期回收闲置超过5分钟的无效连接，减少不必要的资源占用。

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