北京
2025年PostgresConf一份调查扎心了——71%的后端团队承认从没正经调过连接池，直接套用框架默认值。数据库扛得住，应用扛得住，但两者之间的那层"胶水"，才是压垮系统的真凶。
这不是容量问题，是流动问题。
监控仪表盘在骗你
典型场景：连接池上限设为25，仪表盘显示20个空闲连接，5个在排队，API却疯狂返回504。你盯着屏幕想不通，明明有富余，为什么总在超时？
真相是池子里"空闲"的连接，未必真的可用。15个连接可能卡在未提交的事务里，或者被30秒的慢查询霸占，又或者死等一个被其他连接持有的锁。仪表盘说20个空闲，实际可用的可能只有5个。第6个查询进来，等，再等，超时——尽管数字看起来一切正常。
PostgresConf的调查数据背后有个更细思极恐的事实：大多数团队调参的方式是"从教程抄数字，慢了再往上加，然后祈祷"。
有个工程师在日志里盯了三天才发现这个盲区。池指标没撒谎，只是测错了东西。容量（capacity）和可用性（availability）被当成一回事，完全是两个维度。
真正该算的那笔账
忘掉最大连接数。先算这个：峰值瞬间需要多少并发连接才能扛住查询洪峰，不是平均，是峰值。
100 QPS × 0.05秒平均耗时 = 5个连接。数学很简单。但现实很疯：请求不是均匀来的，是突发的。三个高并发请求同时撞上来，你的"5个连接"瞬间被打穿。
更隐蔽的坑是事务边界。一个本该200毫秒的查询，因为嵌在长达10秒的事务里，连接被白白占用。框架默认的池配置从不考虑你的业务事务模式，它只管分配数字。
调参没有银弹。但有个起点：把池大小设成峰值并发需求的2-3倍，然后盯着"连接等待时间"这个指标，而非"空闲连接数"。等时间超过100毫秒就扩容，别等超时了再救火。
那个盯了三天日志的工程师后来把这事写进了团队手册。第一页只有一句话：仪表盘上的绿色，可能是系统窒息前的回光返照。
你的连接池配置，最近一次基于真实流量测算是什么时候？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
