Go 数据库连接断开的处理：重试策略、健康检查与连接预热

在 Go 后端服务里，数据库连接断开是一个看起来很小、却经常把服务拖下水的问题。很多服务第一个版本跑得很顺，没有刻意处理连接异常，直到某天上线新功能后，接口开始时不时返回 500，日志里冒出一堆 EOF 或 connection reset by peer，才意识到连接这个东西并不是建立之后就能一直用的。

这篇文章想聊的不是抽象的 Go 数据库连接原理，而是实际处理连接断开时需要想清楚的三件事：重试该怎么做，健康检查做到什么程度，连接预热有没有必要。这三件事单独看都不复杂，但放在一起，很容易被团队做成“三件套”堆在代码里，最后反而引入新的问题。

连接断开到底是谁的锅

在写重试和检查之前，先得理解连接为什么断开。绝大多数情况下，问题不在 Go 程序本身，而在于运行环境的三个事实：网络不是可靠的、数据库服务端有自己的资源回收策略、中间件可能会主动断连。

比如 MySQL 的 wait_timeout 默认是 8 小时，但很多云厂商的负载均衡或者代理层会设更短的空闲超时。服务如果长期没有请求，连接池里的连接被服务端静默断开，客户端并不知道。等到下一次请求真正发出时，才收到一个错误。

另一个常见场景是服务重启或数据库主从切换后，旧连接已经失效，但连接池里还留着它们。Go 的 database/sql 会在取用连接时检测连接状态，但这种检测并不能覆盖所有情况，尤其在连接已经半开的时候，一次简单的 SetConnMaxLifetime 和健康检查配置如果没做好，服务偶尔还是会踩到坏连接。

还有一个容易被忽略的因素：连接池本身的大小和生命周期配置。如果 MaxOpenConns 设置得很大，而数据库端的 max_connections 很小，高峰期建连失败会直接把服务压垮。这时候重试策略越激进，数据库负载越高，恢复越慢。

所以处理连接断开，核心不是“断了就重连”，而是先理解断开的可能来源，再针对不同来源选择不同的防御方式。

database/sql 连接池：先把它配置对了

Go 标准库的 database/sql 自带连接池，很多项目其实没有充分发挥它的作用，只是默认配置跑着。连接池的几个参数直接影响断连处理的复杂程度：

SetMaxOpenConns 控制最大连接数，SetMaxIdleConns 控制空闲连接数，SetConnMaxLifetime 控制连接的最大存活时间，SetConnMaxIdleTime 控制空闲连接的最大空闲时间。这四个参数里，对连接断开影响最大的是后两个。

很多团队会疑惑：既然连接可能被动断开，那我给连接设一个最大生命周期，定期换新连接不就行了？理论上是这样，但实际配置时有一个典型误区：只设置 ConnMaxLifetime 却不设置 ConnMaxIdleTime。结果是空闲连接一直占用资源，仍然可能出现服务端超时断开后连接池不知情的情况。

一个比较务实的连接池初始化示例：

db, err := sql.Open("mysql", dsn)
if err != nil {
    // 注意：sql.Open 不会真正建立连接
    return err
}

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

这里有个值得强调的点：sql.Open 只是创建了一个句柄，不会验证数据库是否可用。很多项目在这之后直接开始接受流量，如果数据库当时正在抖动，服务就会以错误接口作为开场。解决办法是在启动时主动 PingContext 一次，这同时也是连接预热的基础。

连接池参数不是越大越好，也不是设置完就一劳永逸。它需要和数据库端配置配合，比如 MySQL 的 wait_timeout、云数据库的连接上限。在后续做重试和健康检查时，都要基于这套连接池配置来思考。

重试策略：别让重试成为雪崩因子

遇到连接断开，最简单的想法是“再来一次”。但重试是有代价的，尤其在服务已经依赖数据库的情况下。一个设计不当的重试策略，会在数据库短暂故障时把请求堆积在服务端，反而拖垮整个服务。

首先需要区分哪些错误值得重试。 MySQL 驱动返回的错误里，ErrBadConn 是连接池层明确判断为连接不可用的一种，这类错误重试一次是合理的。但如果是 SQL 语法错误、唯一键冲突这类业务错误，重试没有任何意义。

另一个容易踩的坑是对网络错误的误判。比如读取超时，重试同一个查询可能加重数据库压力；主从延迟导致的读不到新数据，重试也不一定解决问题。好的重试逻辑要显式列出可重试的错误类型，而不是对所有 error 统一处理。

其次要设计退避策略。最简单的是固定间隔重试，但工程上更推荐指数退避，也就是第一次重试等 50ms，第二次等 100ms，第三次等 200ms，并设置最大重试次数。这样在故障持续时能自动放慢节奏，给数据库恢复喘息时间。

下面是一个小工具函数的示例，用于执行带重试的数据库操作：

func ExecuteWithRetry(ctx context.Context, fn func(context.Context) error) error {
    maxRetries := 3
    backoff := 50 * time.Millisecond

    for i := 0; ; i++ {
        err := fn(ctx)
        if err == nil {
            return nil
        }

        if !isRetryable(err) {
            return err
        }

        if i >= maxRetries {
            return err
        }

        select {
        case <-time.After(backoff):
        case <-ctx.Done():
            return ctx.Err()
        }

        backoff *= 2
    }
}

func isRetryable(err error) bool {
    return errors.Is(err, sql.ErrConnDone) ||
        errors.Is(err, io.EOF) ||
        errors.Is(err, driver.ErrBadConn)
}

注意这个函数里用 errors.Is 来判断，是因为数据库驱动返回的底层错误通常被包装过。如果直接比较 error 字符串，很容易漏判。

重试的最大次数不推荐太大。一般 2 到 3 次就足够，超过 3 次对业务成功率提升有限，却会显著增加请求延迟。如果 3 次都失败，更好的处理方式是把请求直接降级或熔断，而不是继续试。

此外，重试必须考虑上下文取消。如果客户端已经超时，服务端仍然在重试只会浪费资源，所以在每轮重试之间要检查 ctx 是否已经取消。

最后，重试策略要区分场景：读操作和写操作的处理方式不同。写操作的重试需要谨慎，因为第一次可能已经执行成功，只是响应丢失，盲目重试会造成重复插入。对于幂等的写操作可以用相同主键重试，否则最好让业务层自己决定如何补偿。

下面用一个简单表格对比常见的重试策略：

如果拿不定主意，线上服务优先选指数退避，后台批处理可以考虑固定间隔。但无论选哪种，都不能忘记设置最大重试次数和总超时预算。

健康检查：Ping 不是万能的

连接池本身有坏连接清理机制，但不够全面。很多团队会在服务里加一个定时器，定期执行 db.Ping 来确保数据库可用。这看起来没错，但 Ping 的作用经常被高估。

Ping 只是向数据库发送一个轻量级的探测命令，确认当前能建立或复用连接。它不能校验业务表是否存在，不能验证权限是否正确，也不能探测到数据库查询性能下降。一个典型的例子：数据库连接正常，但某个关键表被锁了，Ping 依然返回成功，业务请求却会超时。

所以健康检查要区分两个层次：连接层面和业务层面。连接层面的检查由连接池的 Ping 和 ConnMaxIdleTime 负责；业务层面如果对核心存储有强依赖，可以考虑在启动时做一次轻量的查询，确认表结构和基本读写路径正常。但这不代表每次健康检查都去查业务表，那样会给数据库增加额外负担。

另一个常见误区是使用 db.Ping 但不用 Context。在数据库不可用时，Ping 会一直阻塞，直到 TCP 超时，导致服务启动流程被卡住。正确的做法是始终使用 PingContext，并给它设置合理的超时时间，比如 3 秒。

还有一个实践细节：连接池里的连接状态检查其实发生在取用连接时。database/sql 会检测连接是否过期，还会根据驱动的 Ping 能力来验证连接。但这个过程在连接池空闲连接越多时越不可靠，因为空闲连接不会主动被检查。因此，定时任务中运行一次轻量级 PingContext，配合连接空闲过期设置，能有效减少拿到坏连接的几率。

健康检查的另一个正确用法是配合依赖管理。如果服务依赖数据库，那么在健康检查失败时应该让实例暂时不对外提供服务，而不是只是打日志。很多团队把健康检查做成“有检查但无动作”，失去了它本来的意义。

连接预热：启动时的一次握手

连接预热听起来是个高级话题，实际上解决的问题很朴素：让服务在正式接流量之前，就完成连接池的初始建立和验证。

为什么需要预热？因为连接池默认是懒加载的，第一个请求到达时才会创建连接。在流量脉冲式进入的场景下，比如定时任务启动或流量高峰突然来临时，第一个请求往往需要额外付出建连的延迟，还可能出现因为数据库来不及接受新连接而失败的情况。

预热并不是把连接池填满，而是做两件事：一是验证数据库配置和权限是否正确，二是按预期大小建立一部分连接，让数据库端提前接受新连接。一般来说，预热 2 到 5 个连接就足够，不需要把整个连接池都打满。

预热还会暴露配置问题。比如 DSN 写错、用户名密码错误、数据库不可达，这些在启动时就能报错，而不是等到用户请求进来才暴露。在 Kubernetes 这样会频繁重建实例的环境中，这个价值尤其明显。

一个简单的预热实现：

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

if err := db.PingContext(ctx); err != nil {
    return err
}

// 按需建立少量连接
for i := 0; i < 3; i++ {
    go func() {
        ctx, cancel := context.WithTimeout(context.Background(), time.Second)
        defer cancel()
        db.ExecContext(ctx, "SELECT 1")
    }()
}

启动时 Ping 是必须的，后面的并发建立几个连接是可选的。注意并发预热的数量和数据库接受能力要匹配，千万不要在启动时一口气建立 50 个连接，否则数据库会受到压力冲击，预热反而成了事故源。

预热之后，连接池会随着业务流量自然增长。只要连接池参数合理，运行阶段不需要频繁干预。预热真正的目的是消除冷启动的突变，而不是替代连接池的生命周期管理。

把三者组合起来的落地姿势

重试策略、健康检查和连接预热是一个环环相扣的组合，不是一个可有可无的 checklist。很多团队分开实现，但它们只有互相配合才能真正发挥作用。比如没有连接池的参数配合，重试策略可能会在连接池饱和时触发更多冲突；没有预热，健康检查也只能在启动后补救。

落到实际项目中，我建议按这样的顺序来调整代码：

1. 先配置好连接池四个参数，确认和数据库端超时配置匹配。
2. 在服务启动时用 PingContext 做一次健康检查并预热少量连接。
3. 封装统一的数据库操作入口，在关键路径上加上指数退避重试，限定次数和超时。
4. 定时任务里做轻量级 PingContext，失败时让实例摘流量或触发熔断。

这里需要特别提醒的是：不要对每条 SQL 都加上重试。重试对象应该是“数据库请求”，最好是像前面示例那样用一个包装函数统一管理。涉及事务的操作尤其要小心，事务中的重试可能因为部分语句已执行而状态混乱，工程实践中通常要求事务整体重新执行，或者在业务层做幂等处理。

还有一个很多服务都会遇到的场景：数据库主从切换。切换时旧连接全部失效，重连新主库可能还需要更新 DSN。这种场景下，健康检查必须考虑连接的重建能力，连接池参数中的 ConnMaxLifetime 设置得比数据库端超时短一些，能加速连接回收。如果切换频繁，可以考虑引入带路由能力的数据库代理，但这已经超出连接池本身的范畴了。

最后想说，Go 社区对连接池的讨论往往聚焦在参数调优上，但实际线上事故里，连接断开处理不当通常是缺少一个统一的策略。把重试、检查和预热写成公共组件，所有人按规范使用，比每个业务各自写一套要可靠得多。

数据库连接断开的处理没有银弹，只有清楚了底层机制，再针对自己的系统节奏做权衡，才能在故障来临时不慌不忙。