为连接池设置上限、空闲数与生命周期并观察等待指标

Go 的 database/sql 连接池应先设上限，再谈性能。一个服务实例可以把 MaxOpenConns 作为并发连接预算，把 MaxIdleConns 控制在不超过这个预算的范围内，再用空闲时间和生命周期处理连接轮换；最后通过 DBStats 判断请求是在等连接，还是查询本身变慢。连接数盲目放大，往往只是把等待从应用层转移到数据库。

先把连接池参数变成一组可解释的约束

先确定数据库允许的连接预算。例如数据库给整个服务留出 60 个连接、服务有 3 个实例，每个实例的 MaxOpenConns 可以先从 20 附近开始，再根据查询耗时和峰值并发压测。这个数字不是“越大越快”，因为每条连接都可能占用数据库内存、线程或锁资源。

MaxIdleConns 是连接池希望保留的空闲连接数，建议先设为不超过 MaxOpenConns 的一个小比例；如果业务有稳定的突发流量，可以适当提高它，减少请求到来时的建连成本。下面的初始化函数把边界集中在一处：

func openDB(dsn string) (*sql.DB, error) {
    // sql.Open 主要初始化连接池；真正连库用 PingContext 提前确认。
    db, err := sql.Open("driver-name", dsn)
    if err != nil {
        return nil, fmt.Errorf("open database: %w", err)
    }

    // 每个实例最多占用 20 条连接，空闲连接最多保留 8 条。
    db.SetMaxOpenConns(20)
    db.SetMaxIdleConns(8)

    // 空闲 5 分钟回收；连接存在 30 分钟后允许轮换，避免长期复用。
    db.SetConnMaxIdleTime(5 * time.Minute)
    db.SetConnMaxLifetime(30 * time.Minute)
    return db, nil
}

这里的 driver-name 和 DSN 由实际驱动提供，不要把示例直接当成可连接某个数据库的完整配置。服务启动后还应使用带超时的 PingContext，退出时调用 Close。

按连接来源设置空闲时间与生命周期

两个时间参数解决的是不同问题。SetConnMaxIdleTime 面向“连接闲置太久”，适合压低长期空闲连接数量；SetConnMaxLifetime 面向“连接存活太久”，可配合数据库端、代理或负载均衡器的连接轮换策略。它们不是查询超时，也不能替代 context.WithTimeout。

如果生命周期设得过短，流量高峰会出现批量重连，连接池等待和数据库认证压力可能一起上升；如果设得过长，某些中间网络设备已经回收连接，应用才会在下一次使用时遇到错误。因此先记录建连失败、查询错误和连接等待，再逐步调整，而不是直接把时间改成几秒。

用 DBStats 观察等待是否来自池上限

DBStats 提供的是池状态快照。OpenConnections 表示打开连接数，InUse 是正在使用的数量，Idle 是空闲数量；当 InUse 长时间贴近 MaxOpenConns，同时 WaitCount 和 WaitDuration 持续增长，才有理由怀疑请求在等待连接。

func snapshot(db *sql.DB) sql.DBStats {
    // Stats 只读当前池快照；应交给指标系统按固定周期采集。
    stats := db.Stats()
    log.Printf("open=%d in_use=%d idle=%d wait_count=%d wait_duration=%s",
        stats.OpenConnections,
        stats.InUse,
        stats.Idle,
        stats.WaitCount,
        stats.WaitDuration,
    )
    return stats
}

单看 WaitCount 不够：它是累计值，进程重启后会重新开始；WaitDuration 也需要计算一段时间内的增量。把它们与请求延迟、慢查询、数据库 CPU 和错误率放在同一时间窗口，才能避免把慢 SQL 误判成连接池太小。

把超时、健康检查和调参放进验收清单

查询必须继承请求上下文，并设置业务允许的最大耗时；连接池初始化只负责资源边界，不要把数据库连接错误吞掉。验收时可以按下面的顺序检查：

每次只改一个参数，并记录数据库端连接数、应用延迟和错误率。真正可用的连接池配置，应能解释“为什么等待、为什么回收、为什么重连”，而不是只留下一个看似很大的数字。

相关问题

MaxIdleConns 可以大于 MaxOpenConns 吗？

不应这样设计。连接池会把空闲上限收敛到当前最大打开连接数，配置上保持不超过关系更容易排查，也能让连接预算清晰。

WaitCount 增长就一定是连接池太小吗？

不一定。长事务、忘记关闭 Rows、慢查询都会让连接长期处于 InUse；先结合 InUse、查询耗时和数据库负载定位。

SetConnMaxLifetime 能替代查询超时吗？

不能。生命周期控制连接轮换，查询超时应使用带 deadline 的 Context，并让驱动支持相应的取消语义。