Go database/sql连接池 WaitCount 持续增加怎么办

WaitCount 一直增加，先别急着把它当成“当前排队数”。在 database/sql 里，它是连接池历史上发生过的等待次数，只要某个时间窗口内有请求等过连接，累计值就不会回退。真正需要判断的是：最近一段时间是否仍在新增等待、等待了多久，以及 InUse 是否长期贴近 MaxOpenConnections。

我排查这类现象时，会把“累计指标”和“当前池状态”分开采样，再决定是调连接上限、缩短查询占用，还是修复 Rows、事务和独占连接没有及时归还的问题。下面的示例只展示可集成的观察方式，不代表已经连接某个真实数据库。

先确认 WaitCount 不是当前排队数

DB.Stats() 返回 DBStats。其中 WaitCount 是累计等待连接次数，WaitDuration 是累计等待时长；OpenConnections、InUse 和 Idle 则描述采样时刻的池状态。因此，图表上的 WaitCount 单调增加本身并不等于故障持续扩大。

更有意义的做法是每次记录一个快照，用相邻快照计算差值。若五分钟内 WaitCount 增加了 120，而 WaitDuration 也明显增加，说明窗口内确实有人等待；若数值只是历史上升、当前窗口差值为零，就不应只因为总数大而报警。

package poolstats

import (
    "database/sql"
    "time"
)

// Snapshot 保存一个时间点的连接池快照；调用方负责把它交给自己的指标系统。
type Snapshot struct {
    At            time.Time
    WaitCount     int64
    WaitDuration  time.Duration
    Open, InUse   int
    Idle, MaxOpen int
}

// ReadSnapshot 只读取 DBStats，不改变连接池配置，也不触发额外查询。
func ReadSnapshot(db *sql.DB, now time.Time) Snapshot {
    stats := db.Stats()
    return Snapshot{
        At: now, WaitCount: stats.WaitCount, WaitDuration: stats.WaitDuration,
        Open: stats.OpenConnections, InUse: stats.InUse,
        Idle: stats.Idle, MaxOpen: stats.MaxOpenConnections,
    }
}

// Delta 计算观察窗口内的新等待；累计值回绕时交给上层按采集系统规则处理。
func Delta(before, after Snapshot) (int64, time.Duration) {
    return after.WaitCount - before.WaitCount,
        after.WaitDuration - before.WaitDuration
}

这段代码故意没有给出“超过多少就一定异常”的阈值。阈值要和请求量、查询耗时、数据库承载能力以及业务延迟目标一起定。单看绝对 WaitCount，无法区分运行了几小时的服务和刚启动几分钟的服务。

把几个指标放在一起再判断

我通常先看 InUse 是否长期接近 MaxOpenConnections。如果是，同时 WaitCount 和 WaitDuration 在窗口内增长，第一候选是连接池上限或连接占用时间成为瓶颈。但这仍不是“把上限调大”的充分理由：数据库服务端的连接上限、单条 SQL 的耗时和事务锁等待都可能先成为新的瓶颈。

Idle 长期为零并且 OpenConnections 接近上限，说明池里几乎没有可立即复用的连接；如果 InUse 不高，却依然看到等待增长，就应继续查独占 Conn、事务未提交或结果集没有关闭等生命周期问题。反过来，Idle 很多而 WaitCount 在当前窗口不变，通常不需要为了“让总数好看”修改配置。

这也是我不喜欢只看一个指标的原因：WaitCount 告诉你曾经有人等过，WaitDuration 告诉你等了多久，而 InUse/Idle 才帮助判断当时池是否真的被占满。

检查连接、Rows 与事务的归还边界

连接池争用不一定来自并发量突然增加。一个忘记关闭的 Rows、一个迟迟不提交或回滚的事务，或者调用 db.Conn(ctx) 后没有 Conn.Close()，都可能让连接长期处于使用中。共享的 *sql.DB 应该长生命周期复用；业务函数通常不负责关闭整个连接池。

func readUser(ctx context.Context, db *sql.DB, id int64) error {
    rows, err := db.QueryContext(ctx, "SELECT name FROM users WHERE id = ?", id)
    if err != nil {
        return err
    }
    // 结果集由当前函数创建，离开函数前必须归还占用的连接。
    defer rows.Close()

    for rows.Next() {
        var name string
        // Scan 错误要立即返回，不能等到连接池指标间接暴露问题。
        if err := rows.Scan(&name); err != nil {
            return err
        }
        _ = name
    }
    // 遍历错误与查询错误不是同一层，必须单独读取。
    return rows.Err()
}

func updateUser(ctx context.Context, db *sql.DB, id int64) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    // 出错时回滚，成功路径在后面显式提交，避免事务长期占用连接。
    defer tx.Rollback()

    if _, err := tx.ExecContext(ctx, "UPDATE users SET active = ? WHERE id = ?", true, id); err != nil {
        return err
    }
    // Commit 成功后，defer Rollback 不再改变已经提交的事务。
    return tx.Commit()
}

示例中的占位符写法要按所用驱动调整，不能拼接用户输入。Rows.Close、事务的 Commit/Rollback 和独占连接的 Close 关注的是“资源何时归还”；WaitCount 只是结果指标，不能代替代码审查。

按证据选择修复方向

如果确认是合法并发超过池容量，才考虑调整 SetMaxOpenConns；同时要把数据库端连接预算、请求并发和单请求查询耗时纳入决策。只调大上限可能让等待从 Go 连接池转移到数据库线程、锁或 CPU 上。

如果是查询或事务持有连接太久，优先缩短事务范围、尽早关闭 Rows、补齐上下文截止时间，并定位慢 SQL 或锁等待。若只是空闲连接配置不合适，可以单独评估 SetMaxIdleConns；它解决的是复用和空闲保留，不会直接消除一个长期占用连接。

几个容易混淆的问题

WaitCount 会自动清零吗？

不要把它当作当前队列长度。它是连接池累计统计，服务进程持续运行时通常只增不减；监控应记录窗口增量和增量等待时长。

把 MaxOpenConns 设成 0 就能解决吗？

官方语义是小于等于 0 表示不限制打开连接，但这不是通用修复。无限制可能把压力直接推给数据库，连接预算、驱动行为和服务端限制仍然存在。

只看 Idle 为零能判定泄漏吗？

不能。高并发时 Idle 为零可能完全正常；要和 InUse、MaxOpenConnections、WaitDuration 的窗口变化以及 Rows、Tx、Conn 的生命周期一起看。

最后可以把结论压缩成一句话：WaitCount 持续增加只说明历史上发生过等待，是否需要修复，要看当前窗口的新增等待、等待时长和连接占用证据。先修复资源归还与查询占用，再在有数据库容量依据时调整连接上限。

官方资料

database/sql 官方 API 与 DBStats：https://pkg.go.dev/database/sql

Go 标准库 database/sql 实现：https://go.dev/src/database/sql/sql.go