Go 数据库连接池空闲连接为什么突然断开

Go 的数据库连接池空闲连接“突然断开”，通常不是 sql.DB 无缘无故丢连接，而是连接池主动回收、数据库服务端清理，或中间层的空闲超时先后不一致。处理时先确认是谁关的，再让应用侧的回收时间短于外部超时，并保留足够余量。

官方地址：https://go.dev/doc/database/manage-connections

先把“空闲连接断开”拆成三种情况

第一种是 Go 自己回收：配置了 SetConnMaxIdleTime 后，连接超过空闲时长会被关闭；设置了 SetConnMaxLifetime 后，连接达到最长存活时间也会退出。第二种是外部回收：数据库参数、连接代理、负载均衡或 NAT 的空闲时间更短，下一次借用时驱动才暴露“连接已关闭”或“EOF”。第三种是池的容量变化：SetMaxIdleConns 限制的是保留数量，突发流量结束后，多出的连接被收掉并不等于故障。

观察时可以把错误发生时间和池指标放在一起。MaxOpenConnections、OpenConnections、InUse、Idle 反映池的当前状态；WaitCount 和 WaitDuration 更适合判断连接是否不足。它们不能直接证明服务端是否关闭了 TCP 连接，所以还要结合驱动错误和数据库日志。

配置参数要按职责配，不要拿空闲上限当保活

下面的配置表达的是一个常见取舍：应用主动淘汰过老或过久空闲的连接，给数据库和代理留下更短的连接寿命。具体秒数必须以你的数据库、代理和网络设备配置为准。

db, err := sql.Open("driver-name", dsn)
if err != nil {
    // Open 主要检查驱动和 DSN；真正连通性仍需 PingContext。
    return err
}
defer db.Close()

// 让应用主动回收连接，时间应短于外部空闲超时并留出余量。
db.SetMaxOpenConns(40)
db.SetMaxIdleConns(10)
db.SetConnMaxIdleTime(4 * time.Minute)
db.SetConnMaxLifetime(30 * time.Minute)

// 用短超时检查当前是否能建立或复用连接，避免健康检查无限等待。
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
if err := db.PingContext(ctx); err != nil {
    return fmt.Errorf("database ping failed: %w", err)
}

这组数字不是通用答案。若数据库或代理在 5 分钟清理空闲连接，应用的 4 分钟只是示例；若外部超时只有 60 秒，就必须重新计算。MaxIdleConns 过小会增加重连，MaxOpenConns 过小会让请求在池外等待，过大则可能把数据库连接数推过上限。

用一条时间线排查“借用时才失败”

最有价值的复查动作是记录连接池统计的采样时间、请求错误和外部超时配置。若应用空闲 4 分钟后主动收缩，通常能在下一次请求前完成回收；若应用设置 30 分钟，但数据库 5 分钟就清理，错误往往集中在“长时间无请求后的第一笔查询”。这时盲目增大 MaxIdleConns 只会保留更多可能过期的连接。

事务和专用连接要单独守住释放边界

普通的 QueryContext 或 ExecContext 结束后，sql.DB 会把连接交回池中；事务必须明确 Commit 或 Rollback。如果用 DB.Conn 获取专用 sql.Conn，即使遇到错误也要执行 Close，否则连接会长期占用池资源。长查询则应从请求上下文派生超时，让取消动作能够传递给驱动。

常见问题

把 SetMaxIdleConns 调大能防止连接断开吗？

不能。它只改变池最多保留的空闲连接数；数据库或代理仍可按自己的超时关闭连接。

每次查询前都调用 PingContext 更可靠吗？

它能提供一次连通性检查，但也增加往返开销，且检查和真正查询之间仍可能发生变化。更适合健康检查或明确的故障恢复路径。

为什么连接数没满，请求仍然很慢？

检查 WaitCount、WaitDuration、查询耗时和数据库锁等待；“连接数未满”只能说明一个时点的池状态。

排查这类问题的核心不是追求永不关闭，而是让应用、数据库和中间层对连接寿命有一致的预期：应用先回收，外部少做突袭，指标能解释每次重连成本。