Go问答：database/sql DB.Stats MaxLifetimeClosed怎样区分连接寿命回收和空闲回收

排查 Go 数据库连接池时，如果发现 DB.Stats().MaxLifetimeClosed 在增加，先不要把它理解成“当前连接已经关闭了这么多”或“当前连接数异常”。它是一个从 *sql.DB 创建以来累计的关闭计数，表示连接因为 SetConnMaxLifetime 的寿命限制而被关闭的总次数。

最可靠的判断方式是连续采样两次 DBStats，计算 MaxLifetimeClosed 的差值，再和 MaxIdleTimeClosed、MaxIdleClosed 以及连接池阈值一起看。当前池里有多少连接，要看 OpenConnections、InUse 和 Idle。

官方文档：https://pkg.go.dev/database/sql#DBStats

先把 DBStats 分成“当前状态”和“累计计数”

我第一次遇到这个指标时，最容易犯的错误是把一组数字放在一起比较，却没有先区分它们的时间语义。DBStats 里有两种完全不同的数据：

因此，OpenConnections=8、MaxLifetimeClosed=125 并不矛盾：前者是现在池里有多少条连接，后者是历史上因为寿命策略关闭过多少条连接。后面这个数字只增不减，进程重建 *sql.DB 后才会重新开始累计。

三类关闭计数到底对应什么

三个字段的名字很像，但触发条件不一样。排查时先回到配置，而不是只盯着计数器。

MaxLifetimeClosed：连接年龄超过寿命

db.SetConnMaxLifetime(d) 设置的是连接可以被复用的最长时间。它描述的是连接年龄，不是一次请求持续多久。文档说明，过期连接可能在再次复用前被惰性关闭；因此计数增加的时间点不一定就是它刚好达到年龄上限的时间点。

MaxIdleTimeClosed：连接闲置太久

db.SetConnMaxIdleTime(d) 关注的是连接处于空闲状态的时长。一个连接可以总年龄不大，却因为一段时间没有被使用而触发这个规则。它与连接寿命策略可以同时配置，不能仅凭“连接最近没有请求”就断定是 MaxLifetimeClosed。

MaxIdleClosed：空闲连接数量超过上限

db.SetMaxIdleConns(n) 管的是空闲池容量。当一次并发高峰结束后，归还到池里的连接超过允许保留的空闲数量，超出的部分会被关闭并计入 MaxIdleClosed。它是数量边界，不是时间边界。

可以把它们简化成一句判断：年龄看 MaxLifetime，空闲时长看 MaxIdleTime，空闲数量看 MaxIdle。如果同一时间窗口内多个计数器都在增加，要结合采样间隔和配置阈值，不要强行把一次回收归给唯一一个原因。

用两次采样差值判断寿命回收

因为关闭计数是累计值，监控系统应该记录时间窗内的增量。下面的示例只演示读取和判断逻辑，不依赖某个具体数据库驱动：

package main

import (
    "database/sql"
    "fmt"
    "time"
)

type poolDelta struct {
    lifetime int64
    idleTime int64
    idleCount int64
}

func sampleDelta(before, after sql.DBStats) poolDelta {
    // 三个字段都是累计计数，必须用后一次减前一次。
    return poolDelta{
        lifetime: after.MaxLifetimeClosed - before.MaxLifetimeClosed,
        idleTime: after.MaxIdleTimeClosed - before.MaxIdleTimeClosed,
        idleCount: after.MaxIdleClosed - before.MaxIdleClosed,
    }
}

func printPoolState(db *sql.DB) {
    stats := db.Stats()
    // 当前状态只描述此刻，不要和累计关闭数混为一谈。
    fmt.Printf("open=%d in_use=%d idle=%d lifetime_closed=%d\n",
        stats.OpenConnections,
        stats.InUse,
        stats.Idle,
        stats.MaxLifetimeClosed,
    )
}

func observe(db *sql.DB) {
    first := db.Stats()
    time.Sleep(10 * time.Second) // 示例采样间隔，生产环境应交给监控调度。
    second := db.Stats()
    delta := sampleDelta(first, second)

    switch {
    case delta.lifetime > 0:
        fmt.Printf("寿命回收新增 %d 条\n", delta.lifetime)
    case delta.idleTime > 0:
        fmt.Printf("空闲时长回收新增 %d 条\n", delta.idleTime)
    case delta.idleCount > 0:
        fmt.Printf("空闲数量回收新增 %d 条\n", delta.idleCount)
    default:
        fmt.Println("本采样窗口没有观察到关闭计数增加")
    }

    printPoolState(db) // 同时保留当前池状态，便于解释连接数变化。
}

示例中的 switch 适合“只想给出第一判断”的场景。真实监控不要使用互斥的单分支结果，而应把三个差值同时上报，因为同一个时间窗可能有多种回收规则生效。

遇到 MaxLifetimeClosed 增长时按这个顺序排查

1. 先确认是否设置过寿命。搜索所有 SetConnMaxLifetime 调用，确认是否存在初始化代码、测试代码或配置热更新。
2. 记录两次累计值。不要只看某一次绝对值，保存 t1、t2 和差值，明确增长发生在哪个时间窗。
3. 同时记录三个关闭计数。如果只有 MaxLifetimeClosed 增长，寿命策略是首要线索；如果空闲相关计数也增长，需要继续对照空闲规则。
4. 把当前状态放在旁边。将 OpenConnections、InUse、Idle 一起记录，判断是连接轮换、流量下降，还是池容量发生变化。
5. 检查采样窗口和连接使用节奏。过期连接可能在下一次复用前才被惰性关闭，所以计数增加可能落在请求恢复之后，而不是刚达到阈值的瞬间。

我实际更愿意把“计数增长”当成线索，而不是故障结论。设置较短的连接寿命本来就会让 MaxLifetimeClosed 持续增长；只有当它伴随连接建立频率异常、握手成本升高、数据库端连接压力或请求延迟上升时，才需要继续评估寿命阈值是否过短。

几个容易误判的边界

MaxLifetimeClosed 增加，说明连接泄漏了吗？

不说明。它反而说明连接池按寿命规则关闭了一些连接。连接泄漏更应该结合 InUse 长期不回落、Idle 异常减少、请求资源未释放等现象判断。

把 SetConnMaxLifetime 设为零就不会再有关闭计数了吗？

它只表示不因连接年龄关闭；空闲时间、空闲数量、数据库端主动断开以及显式关闭仍可能影响其它字段或连接状态。不要把一个配置的关闭规则等同于所有关闭来源。

为什么计数增加时 OpenConnections 没有明显下降？

连接关闭后，后续请求可能很快创建新连接，当前状态只反映采样瞬间；而关闭计数记录历史累计事件。两者时间语义不同，出现“累计增加但当前数量稳定”是正常的。

监控应该采集绝对值还是增量？

两者都可以保留，但告警和趋势通常应该使用增量或每秒增量。绝对值适合展示进程生命周期内的累计情况，增量更适合回答“最近这十分钟是否发生了寿命回收”。

总结

MaxLifetimeClosed 不是当前连接数，也不是错误次数；它是因 SetConnMaxLifetime 关闭连接的累计计数。排查时先把 DBStats 分成当前状态和累计计数，再用两次采样计算差值，同时对照 MaxIdleTimeClosed 与 MaxIdleClosed。这样才能把“连接在轮换”与“连接池真的异常”区分开。