Go 数据库连接池被打满怎么办：sql.DB 等待数上涨的排查手册

Go 服务接口突然变慢，日志里又没有明显 panic，数据库连接池被打满是很值得优先排查的典型问题。database/sql 里的 *sql.DB 本身就是连接池，不是单条数据库连接；当 MaxOpenConns 到顶、WaitCount 持续上涨时，新的数据库请求会自动排队等可用连接。线上处理时先看连接池核心指标和异常慢接口，再决定是降载止血、回滚新版本、临时调大连接数，还是继续深挖慢查询、长事务和未正常释放的 Rows。

接口排队时先看连接池资源余量

连接池问题最典型的现象是：数据库 CPU 不一定跑满，但接口耗时明显变长；应用日志里偶尔出现 context 超时报错；同一时间段内全局请求量或者某类慢接口占比显著升高。这个时候别上来就死磕单条 SQL 文本，先确认连接池是不是已经用满。

用 DBStats 快速确认池子是否打满

Go 标准库暴露的接口可以直接从 db.Stats() 拿到完整的连接池运行状态。建议把这些指标提前接入监控系统，临时排查时也可以通过管理接口或者实时日志输出当前状态。

stats := db.Stats()

log.Printf(
    "db open=%d in_use=%d idle=%d wait_count=%d wait_duration=%s",
    stats.OpenConnections,
    stats.InUse,
    stats.Idle,
    stats.WaitCount,
    stats.WaitDuration,
)

如果 InUse 长时间接近 MaxOpenConnections，Idle 又处于极低水平，同时 WaitCount 和 WaitDuration 持续上涨，就可以先按连接池排队场景处理。这个判断不等于数据库本身一定慢，但足以说明应用侧已经没有多余的可用连接分配给新请求。

先控制线上风险，再排查慢查询和事务

线上已经出现大量请求排队时，优先把故障影响范围收窄。常见操作分三类：临时降低入口并发流量、摘掉异常实例、回滚刚发布的有嫌疑的版本。不要一上来就直接把 MaxOpenConns 拉得非常大，因为数据库本身的承接能力也有上限，应用侧无节制多开连接反而会把数据库压得更难响应。

止血完成后再逐一排查这几类常见根因：

慢查询耗时变长
事务打开后迟迟不提交
Rows 没有 Close
单个请求里串行查太多次数据库
后台任务和在线流量抢同一个连接池

其中 Rows 没有正常关闭很容易被忽略。只要查询返回了 *Rows，就应该在确认没有错误后尽快执行资源回收操作 defer rows.Close()，否则连接的归还流程会被一直卡住。

连接数调整怎么操作才不容易引发次生问题

SetMaxOpenConns 不是设置得越大越好。它控制单个应用实例最多能打开多少条数据库连接，值太小会频繁触发排队，值太大可能直接超出数据库承载阈值拉高全局延迟。更稳妥的做法是结合数据库实例规格、服务副本总数和常规接口耗时一起综合计算。

db.SetMaxOpenConns(80)
db.SetMaxIdleConns(20)
db.SetConnMaxLifetime(30 * time.Minute)
db.SetConnMaxIdleTime(5 * time.Minute)

如果一个服务部署了 10 个副本，每个副本的 MaxOpenConns 设置为 100，理论上全量运行后最多可以打 1000 条数据库连接。这个数值要提前和数据库最大连接数、其他共享该库的服务连接占用、运维保留余量一起核算。生产环境更建议先小步调整参数，再持续观察 WaitCount、数据库 CPU、慢查询数量和接口错误率的变化。

故障恢复后要确认排队现象完全消失

执行回滚或者降载操作后，不要只看到接口返回 200 就直接结束排查。至少要确认三件事：WaitCount 不再快速上涨，InUse 从高水位回落，接口 P95/P99 耗时恢复到平时的正常水位。如果数据库侧慢查询占比仍然很高，说明只是缓解了连接池的排队压力，引发故障的根因还没有完全处理干净。

复盘阶段还要补两类告警规则：连接池排队告警和慢接口告警。连接池告警可以盯 WaitCount 增量、WaitDuration 增量、InUse / MaxOpenConns 占比；慢接口告警则可以帮你快速定位到底是哪条业务路径长时间占住了连接资源。

相关问题

Go 里的 sql.DB 需要每次请求都新建吗？

不需要。*sql.DB 本身就是封装好的连接池，通常在进程启动时创建一次全局复用就可以。每个请求都新建独立连接池会带来不必要的额外开销，也很难统一管控全局连接数。

MaxOpenConns 设置大一点是不是就不会出现排队？

只能暂时缓解应用侧的排队问题，没法解决数据库侧的承接能力上限问题。如果慢查询和长事务的问题没有处理，盲目调大连接数反而可能把数据库压得响应更慢，故障影响面扩散得更广。

WaitCount 上涨一定是数据库慢导致的吗？

不一定。这个指标只说明等待连接的请求次数在增加，背后的原因可能是数据库响应慢、配置的连接数太小、事务持有的时间太久，也可能是代码逻辑没有及时关闭 Rows 导致连接没法正常归还。

后台任务要和在线接口共用一个连接池吗？

按业务风险等级判断。高并发批量后台任务很可能抢走在线接口的连接资源，核心在线接口最好单独配置限流逻辑或者独立的连接池，避免批处理任务把线上用户的请求拖慢。