Database Connection Pool 在生产中的几个常见问题
关于 pool sizing、长事务、connection leak、failover storm、PgBouncer
很多同学第一次做 backend 项目时，对 Database connection pool 的理解非常“朴素”。
“不就是连数据库的连接数控制一下吗？”
HikariCP(Java 项目里常用的高性能数据库连接池) 里把 maximumPoolSize 设成 50，或者 SQLAlchemy(Python 生态里最常用的数据库工具包之一) 里把 pool size 设成 20，应用跑起来，接口也通了。看上去没问题。
问题是，connection pool 这种东西，平时安安静静。一出事，往往不是小事。
我见过最典型的一类事故：CPU 不高，内存没满，数据库本身也没挂，API P99 却从 40ms 直接飙到 8s。应用线程全卡在 getConnection()。LOG看起来像超时，同学第一反应是“数据库慢了”。其实不是， 而是connection pool starvation， 是 pool 被“饿”死了。
而且这种问题，面试里也越来越常见。
现在很多 NG / 0-3 YOE 的 project deep dive混杂一些system design，面试官不会只停留在“你用了 Postgres + ORM + cache”。他会继续问：pool 怎么配？长事务怎么办？failover 时旧连接怎么清？如果你前面挂了 PgBouncer，prepared statement 会发生什么？
90% 的同学第一反应都是：把 pool 开大一点。
没用。很多时候还更糟。
1. Pool sizing 不是“并发请求数 = 连接数”
最常见的误解，就是把 pool size 和 HTTP 并发直接绑定。
比如服务峰值 800 QPS，应用层有 64 个 worker thread，于是有人很自然地说：那 pool 至少得配 64，甚至 128，不然请求排队。
这套想法在生产里经常把系统配死。
为什么？因为数据库不是 CPU bound 的 web server。数据库真正贵的不是“有没有连接对象”，而是每条连接背后都在争 shared buffer、lock、WAL flush、execution slot。你把连接开大，不等于吞吐线性增长。很多时候到了 32、48、64 之后，TPS 不涨了，context switch 和 lock contention 先上来了。
我以前面试会这样问：
我：你的服务 200 个并发请求，pool 要配多少？
候选人：那就至少 200，不然每个请求拿不到连接。
我：你的请求里，真正持有连接执行 SQL 的时间占整个请求生命周期的多少？
候选人：呃……可能几十毫秒？
我：那剩下的时间在干嘛？
候选人：等下游，做 JSON serialize，跑业务逻辑。
我：那你为什么要给每个并发请求都准备一条 DB connection？
到这里，很多人就答不上来了。
真实系统里，pool sizing 通常是从 database capacity 反推，不是从 app 并发正推。你会看单条 query 的平均持有时间、P95/P99、数据库 CPU saturation 点、锁等待比例、事务里是否混入 RPC，然后做一个保守池子。比如一个 Postgres primary 16 vCPU、OLTP workload、query 比较短的场景，应用总连接数控制在 40-80 可能就差不多了，再往上常常收益很差。
真正的 fix 不是“多开连接”，而是：
把 read/write path 分开，别所有请求都进主库
缩短 connection hold time
对慢 query 做 index 或 query rewrite
在 app 层做 backpressure，而不是让数据库当排队系统
代价也很明确：你在 app 层做 backpressure，就意味着高峰期会更早 reject 一部分流量。听起来残酷。
但这是可控的残酷。
总比把 primary 压到所有请求一起超时强。
2. 长事务不会把 CPU 打满，但会把 pool 饿死
这个坑特别阴。
因为监控表面上往往不好看出来。
我接手过一个 billing service，Java + Spring + Postgres，平时 1.5k QPS，HikariCP 配 40。事故那天 API error rate 从 0.3% 涨到 18%，但数据库 CPU 只有 42%，内存也够，磁盘 util 甚至不到 50%。乍一看不像 DB 问题。
后来查 thread dump，发现应用里 37 条线程都卡在等 connection。再往下看，真正拿着连接不放的，是 6 个长事务——每个事务里先查 DB，再调外部 tax service，再等 S3 生成 invoice PDF，整个 transaction 活了 4 到 9 秒。
这就叫自杀式写法。
很多人写代码时觉得只要 @Transactional 包起来就安全。实际上你把 network call、S3 upload、第三方 RPC 混进事务，就是拿最贵的资源去等最慢的外部世界。
connection pool 里的每一条 connection 都像 ICU 床位。你拿着床位去楼下买咖啡，后面真正要抢救的人就进不来了。
这类问题的industry best practices通常有几种：
缩事务边界：DB state change 和外部 side effect 拆开，不要一个 transaction 包天下
Outbox pattern：先本地提交订单状态，再异步发 event，让下游处理 PDF / email / webhook
SELECT ... FOR UPDATE SKIP LOCKED 这种锁策略只放在真正短临界区里，不要包业务编排
对 ORM 默认 lazy loading 保持警惕，很多“无害”的对象访问会在事务末尾多打几条 SQL
代价是什么？
代价是代码复杂度上升。你从“一个事务包到底”变成显式状态机，可能还要加 reconciliation job、dead letter queue、重试语义。工程上更麻烦。
但这才是 production。
3. Connection leak 很少是“忘了 close”这么简单
大家一听 connection leak，第一反应通常是：谁忘了 finally close()。
有时候确实是。
但很多更麻烦的 leak，不长得这么明显。
尤其是 async runtime、ORM session、cursor streaming 这些场景。
我见过一个 Python 服务，FastAPI + SQLAlchemy，平时没事，一到凌晨 batch job 就把 pool 慢慢吃空。不是瞬间空。是 40 分钟里一点点掉到 0。最后所有 API 都卡死。
最后怎么定位的？
不是看 error log。是看 pool metrics：checked_out_connections 一直涨，checked_in_connections 回不来。然后顺着 trace 找，发现某个导出接口为了省内存，用 server-side cursor 流式扫 1200 万行数据。开发以为 response 返回完就结束了，实际上 client 中途断开连接时，那条 cursor 没被 clean up，connection 一直占着。
还有一类坑，是 async context 里 session 生命周期管理不对。比如你在 coroutine A 创建 session，把对象传进 coroutine B，异常路径没走回收钩子；或者框架升级后 middleware 顺序变了，原来依赖 request-scope cleanup 的逻辑失效了。这些 leak 平时很难炸，一有长尾异常流量就露馅。
真正靠谱的修法不是靠 code review 祈祷，而是三层一起做：
Pool metrics：必须暴露
active / idle / pending / timeout / max lifetime evictionsLeak detection threshold：像 HikariCP 的 leakDetectionThreshold，超过 2s 或 5s 打堆栈
Structured lifecycle ownership：session / cursor / transaction 谁创建谁销毁，别靠隐式魔法
如果是长流式查询，很多时候你还得单独走 bulk path，不要跟在线请求共用同一个 pool。甚至直接拆到 read replica 或 batch worker 上。
代价？
代价是你要接受“不是所有数据库访问都该共用一套 abstraction”。很多团队特别迷恋统一。统一 ORM，统一 session helper，统一 middleware。
听起来很优雅。 炸起来也很统一。
4. Failover 的时候，connection rebuild storm 会把新 primary 再打死一次
这个坑是很多人完全没经历过的。
他们以为 failover 就是旧 primary 挂了，新的顶上来，应用自动重连，世界恢复和平。
真实情况常常是：旧 primary 被拿掉， RDS/Aurora 这类托管或自动 failover 方案通常能在几十秒到一两分钟内完成切换。这个窗口里，应用侧几百个 instance 同时发现 connection broken，于是一起重连。假设 300 个 pod，每个 pod pool size 30，那一瞬间理论上会有 9000 条 connection attempt 打向新 primary。
刚切主的新 primary cache 还是冷的，replication 状态刚稳定，连接 storm 再灌进去一次，直接把它打到 authentication queue 爆掉。
我之前见过一次更夸张的：应用加上 sidecar 和 worker 一共 480 个进程，failover 后 20 秒内发了 1.7 万次 TLS handshake。数据库没死在原故障。
死在恢复阶段。
这类问题的 fix 不是单一参数，而是一整套节流策略：
Exponential backoff + jitter，而且 jitter 不能是摆设
对 pool 初始化做 staggered warmup，别所有 instance 一起把 minIdle 补满
把 fail-fast 和 fail-silent 分层：有些请求宁愿快速报错，也别无限阻塞拿连接
使用 RDS Proxy / PgBouncer / ProxySQL 这类 proxy 吸收部分 churn，但别神化它们
在应用层加 circuit breaker，数据库 failover 窗口里主动降载
这里的 trade-off 非常现实：你把 reconnect 做得保守，恢复窗口里一部分请求会失败得更明显；你做得激进，新 primary 可能恢复不过来，整站一起挂更久。
没有免费午餐，只有更不坏的选择。
5. PgBouncer 不是“挂上去就行”，transaction pooling 会改写你的连接语义
很多团队数据库顶不住时，会想到前面挂 PgBouncer。
这方向经常是对的。
但很多候选人和很多线上团队一样，都低估了它改变的不是“连接数量”，而是连接语义。
最典型的是 transaction pooling。
在 session pooling 模式下，你的 client connection 基本持续绑定同一个 backend connection；到了 transaction pooling，事务一结束，backend connection 就还回池里，下一次你拿到的可能是另一条。于是很多原本你以为“天然成立”的东西都不成立了：
依赖单条 backend connection 的 prepared statement 可能失效。
SET search_path、SET ROLE、SET timezone这种 session state 不能再偷懒依赖连接粘性temp table 逻辑会出问题
某些 ORM 默认行为会和 proxy 模式冲突
我面试一般会这么追问：
我：你们用了 PgBouncer，pool mode 是什么？
候选人：transaction pooling。
我：prepared statement 怎么办？
候选人：啊？prepared statement 不是数据库会处理吗？
我：如果 driver 以为自己还连着原来那条 backend connection，但下一次事务已经被分配到另一条了呢？
到这里，很多人就沉默了。
更常见解决方案是：
明确 driver / ORM 是否支持 PgBouncer transaction pooling
必要时关闭 server-side prepared statement，或确认 driver / PgBouncer 的配置能兼容 transaction pooling。
所有 session state 改成显式设置，别假设连接有记忆
把 migration、long-running admin task、online traffic 分开，不要全走同一个 proxy policy
代价也不小。
你可能会损失一部分 prepared statement 带来的性能收益；也可能要改掉一批默认 ORM 配置，连 staging 都要重测一轮。很多团队就是在这一步偷懒，于是线上出现“偶发错、无法稳定复现”的幽灵 bug。
为什么这些问题会直接决定面试结果
因为 2026 的面试环境里，单纯“会用 ORM 连数据库”已经完全不是信号了。
那只是门槛。
真正把 hire 和 strong hire 拉开的，是你有没有把资源争用、failure mode、proxy semantics、恢复窗口这些 production 级约束内化成反射。面试官追问 connection pool，本质不是考你背没背参数名，而是在看：你是不是知道系统会怎么坏。
知道“怎么搭起来”和知道“怎么坏掉”，是两种完全不同的工程 level。
这个 gap 怎么补
如果走纯自学路径，补这类 gap 往往要 3 到 5 年。
你得先进大厂或者高流量团队，值几轮 on-call，亲手吃几次 connection starvation、failover storm、锁等待打爆，再写几份像样的 post-mortem，才会真的长出这种判断力。
问题是，很多人拿 offer 之前，面试官就已经在问这些了。
你没有那 3 到 5 年。
而且一次关键面试机会浪费掉，可能就是 6 个月 cooldown，或者整个秋招窗口直接错过。学校不教这个。绝大多数公司也不会因为你“有潜力以后学会”就先把 offer 发给你。
现实很残酷。
这也是我现在做辅导时特别核心的一块：不是只帮你把项目“做出来”，而是把你现有的 backend / distributed systems 项目拆开，看哪些地方在 production 下一定会出问题，然后把这些 failure mode 重新长回你的设计和表达里。
比如一个很普通的 CRUD + Postgres 项目，怎么重构到能接住“pool sizing 怎么反推”“长事务为什么会饿死连接”“failover 时为什么会出现 reconnect storm”这种追问；再比如你面试时如果被问到“read replica lag 下连接路由怎么做”“PgBouncer transaction pooling 会破坏什么假设”，怎么答才像一个真正想过系统怎么坏的人。
这些东西，学校不教。公司也不会等你学会了再给你 offer。