备案站点的数据库连接池与连接数治理

「连接池满了」背后往往不是池太小

一看到 connection pool exhausted 就把池大小从 20 调到 200，是最常见也最危险的处理方式。数据库连接是稀缺资源：每个连接在数据库侧都要占内存、参与调度，连接数翻十倍通常不会让吞吐翻十倍，反而会因为上下文切换和锁竞争让整体更慢。

关键要点

• 池满几乎总是「下游变慢」的症状，而不是根因——先查慢在哪，再谈调大。
• 池大小要和数据库的最大连接数对齐：应用实例数 × 单实例池大小才是真实占用。
• 连接泄漏的典型特征是池占用只升不降，重启后恢复一段时间又复发。
• 长事务会把连接和锁一起长期占住，是隐形杀手。

容量估算：先算再配

稳态下的并发连接需求约等于 QPS × 平均响应时间。例如 200 QPS、平均 50 毫秒，需要的并发约为 10；留一倍余量，池大小 20 已经够用。反过来，如果响应时间从 50 毫秒劣化到 1 秒，同样 QPS 下需求会变成 200——这正是「池满」的真实成因：下游变慢，而不是流量变大。

再往上一层算总量：

项	示例	说明
应用实例数	6	含弹性扩容后的峰值实例数
单实例池大小	20	每个实例各自持有
后台任务/定时任务	10	容易被忘记统计，见 定时任务运维
运维与迁移工具	10	预留，别把额度用满
合计	140	必须小于数据库最大连接数

弹性伸缩会让实例数在高峰翻倍，估算时要按峰值实例数算，见 容量规划与弹性伸缩。

五个关键超时参数

参数	作用	配错的后果
获取连接超时	等不到连接时快速失败	不设会让请求无限排队
连接建立超时	握手阶段的上限	数据库不可达时线程全卡住
查询超时	单条 SQL 的上限	一条慢 SQL 占住连接数分钟
空闲回收时间	回收闲置连接	过短导致频繁重建，过长浪费额度
最大存活时间	强制重建连接	不设会撞上数据库或中间件的单边断连

最大存活时间常被忽略：数据库或负载均衡通常会单方面关闭空闲超时的连接，而应用侧并不知情，直到下一次使用时才报出莫名其妙的连接错误。把应用侧的最大存活时间设得短于数据库侧的等待超时即可避免。这些参数要和上游的调用超时统一规划，见 超时设置与重试策略。

连接泄漏：定位方法

症状很典型：池占用单调上升、从不回落，重启后恢复，过几小时又满。常见原因是异常路径上没有归还连接、手动管理事务时漏了提交或回滚、把连接对象存进了长生命周期的对象里。

定位手段：开启连接池的泄漏检测（超过设定时间未归还就打印持有处的堆栈）；在监控里同时观察活跃连接数、空闲连接数、等待线程数三条曲线，指标接入见 可观测性建设。

长事务：比慢查询更麻烦

一个事务里夹了远程调用或人工确认，事务就会持续几秒甚至几分钟。它同时占住连接、持有锁、阻塞其他写入，还会让数据库的历史版本堆积、拖慢所有查询。原则很简单：事务只包住必要的数据库操作，远程调用、发消息、发邮件全部移到事务之外，异步化做法见 消息队列与异步任务运维。

读写分离下的连接治理

引入只读从库后，池要按主库、从库分开配置和监控，否则报表把从库压满时，你在主库的指标上完全看不出来。主从架构与延迟处理见 数据库运维与高可用；慢 SQL 本身的优化见 慢查询定位与索引优化。

常见坑

• 池满就调大：把数据库压得更死，问题从应用转移到数据库。
• 忘记乘以实例数：单实例看着合理，扩容后直接打满数据库额度。
• 不设查询超时：一条慢 SQL 拖住一个连接几分钟。
• 不设最大存活时间：周期性出现莫名的连接中断。
• 事务里做远程调用：连接与锁被外部依赖的响应时间绑架。

常见问题

池大小到底该配多少？

从 QPS × 平均响应时间算出稳态需求，留一到两倍余量，再确认「实例数 × 池大小 + 后台任务」小于数据库最大连接数的七成。多数中小站点单实例 10～20 就足够，配到几百通常是在掩盖慢查询问题。

为什么调大连接池之后反而更慢了？

数据库的并行处理能力受 CPU 与磁盘限制，超过这个数之后增加连接只会加剧上下文切换和锁竞争。表现就是吞吐不涨、延迟普遍变高。

连接数报警应该设在哪个指标上？

优先设在「等待获取连接的线程数」和「活跃连接占池比例」上，它们比总连接数更早反映问题。数据库侧再配一条总连接数接近上限的告警，见 备案网站监控告警体系。

多个服务共用一个数据库，连接额度怎么分？

按服务分配额度并写进文档，给运维和迁移工具预留固定份额。否则一次批量任务就能把额度吃光，导致所有在线服务同时拿不到连接。

资料来源

主流连接池组件（如 HikariCP、pgbouncer）与 MySQL、PostgreSQL 官方文档中关于连接管理、超时参数与最大连接数的公开说明。本文为通用运维说明，仅供参考，具体以实际框架与数据库配置为准。