sql.DB连接池空闲连接怎么调

调 Go 的 sql.DB 空闲连接，应同时考虑“最多保留多少条”和“闲置多久可以回收”：前者用 SetMaxIdleConns，后者用 SetConnMaxIdleTime。先用 SetMaxOpenConns 明确单个连接池的总量预算，再结合数据库容量、实例数量和流量间隔调整；没有通用的最佳空闲数。

官方文档：https://go.dev/doc/database/manage-connections，接口说明：https://pkg.go.dev/database/sql。下面以共享数据库的服务为场景，示例代码是配置与记录片段，没有虚构压测数据或实测收益。

先保护数据库的连接预算

遇到“业务已经低峰，数据库却还有很多连接”，我会先画出每个进程持有多少个 DB，而不是立刻把空闲数设为零。sql.DB 是支持并发使用的连接池句柄，通常在初始化时建立并共享；每个请求都新建一个 DB，会让预算变得难以追踪。

要保护的资源包括数据库可用连接额度、服务建立连接的开销和正在执行的业务请求。预算不仅要看单个进程，还要覆盖最大副本数量、同一进程的读写池以及其他客户端。滚动发布时新旧实例可能同时存在，也应计入容量规划。

例如分配给某服务的额度是假设的120条连接，计划最多4个实例，且每实例只有一个连接池；单池最大24条意味着该服务池上限合计96条，剩余24条作为这份分配中的余量。这里的120、4和24只是算术示例，不能代替数据库实际限额或其他服务预留。若一个实例有两个池，必须分别计入。

看清三类资源风险

这里的风险来自资源争用和配置失衡，不需要假设遭到攻击。第一类是空闲保留过多：低峰仍占用数据库会话资源，尤其在副本增多时容易放大。第二类是保留过少或闲置时间过短：相邻流量波峰无法充分复用连接，可能增加建连、认证等开销。第三类是连接仍被业务借用：长事务、未关闭的 Rows 或未释放的专用 Conn，需要处理相应生命周期，单调空闲参数帮不上忙。

判断优先级时，我更关心请求是否超时、数据库是否接近容量边界，然后才是低峰曲线是否“好看”。把 Idle 降到零只是一个数值结果，不能单独证明资源配置合理。

用四个参数控制数量与时间

SetMaxOpenConns 限制池内打开连接总量；SetMaxIdleConns 限制其中空闲部分的保留量，不是最小保活数量，也不会预先创建指定数量的连接。SetConnMaxIdleTime 管连续闲置时间，SetConnMaxLifetime 管连接可复用的总寿命。这两个时间维度不能互相替代。

package poolconfig

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

// Configure 在应用初始化时配置已有DB；不创建新连接池，也不关闭调用方的DB。
func Configure(db *sql.DB, maxOpen, maxIdle int, idleTime, lifeTime time.Duration) error {
    if db == nil {
        return fmt.Errorf("数据库句柄不能为空")
    }
    // 本应用要求显式预算；标准库本身允许不限制最大连接数。
    if maxOpen  maxOpen {
        return fmt.Errorf("要求最大连接数为正，空闲数在0到最大连接数之间")
    }
    if idleTime 

这个函数适合放在已有数据库初始化代码旁，由配置系统提供参数。例如在前面的预算假设下，可先讨论 maxOpen=24、maxIdle=6、idleTime=2分钟、lifeTime=0 这一组观察起点；是否采用要看业务波峰间隔和基础设施要求，不能直接照搬到线上。原有驱动注册、DSN与句柄的创建和退出关闭仍由应用负责，不需要为了这段配置新建第二个池。

标准库对零值的语义不同：MaxIdleConns 不大于零时不保留空闲连接；MaxOpenConns 不大于零时不限制打开数量；两个时间参数不大于零时不按对应时间回收。空闲上限若高于一个正的最大打开数，会被收敛到总量上限。代码在应用层提前拒绝这类配置，便于发现配置意图不一致。

过期连接可能在复用前被延迟关闭，不能把时间设置理解为精确到秒的强制断开正在执行的查询。服务端或代理的断连策略是另一套约定，须查对应基础设施的文档；池设置不能保证任意网络故障下的连接有效性。

记录变化而不是盯着一个Idle数值

OpenConnections、InUse 和 Idle 是当前状态；WaitCount、WaitDuration、MaxIdleClosed、MaxIdleTimeClosed 和 MaxLifetimeClosed 是累计计数或时长。累计值很大可能只是运行得久，比较相同长度窗口内的增量更有用。下面是可放在同一个 package 中的记录函数，调用方负责保存前后快照并安排采样。

package poolconfig

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

// ReportWindow 由调用方在固定窗口采样；两个快照须来自同一个未重建的DB。
func ReportWindow(out io.Writer, before, after sql.DBStats) error {
    waits := after.WaitCount - before.WaitCount
    waited := after.WaitDuration - before.WaitDuration
    idleClosed := after.MaxIdleClosed - before.MaxIdleClosed
    idleExpired := after.MaxIdleTimeClosed - before.MaxIdleTimeClosed
    lifeExpired := after.MaxLifetimeClosed - before.MaxLifetimeClosed
    // 负差值意味着样本不连续，不能作为正常窗口指标使用。
    if waits 

MaxIdleClosed 增长反映因空闲数量限制而关闭的连接；MaxIdleTimeClosed 对应闲置时间回收；MaxLifetimeClosed 对应寿命回收。这些都不是错误计数，也不是全部新建连接次数。要判断重连是否影响业务，还需结合驱动或数据库侧建连指标、请求延迟与吞吐量。等待时长增量来自池等待，不能直接充当 SQL 执行时间。

记录时附上实例、连接池名称、配置版本和窗口长度即可，不要把 DSN、口令或完整业务参数放进日志。DBStats 不含事务内容，排查连接占用仍需应用层的生命周期记录。改变参数时留下旧值，出现延迟上升或容量压力时才有明确的回退依据。

调整后的观察清单与常见问题

我的取舍方式是先固定总量预算，只改变一个与现象匹配的空闲维度，再对比相近流量窗口：低峰占用是否下降，后续波峰是否增加建连开销，池等待和请求延迟有没有恶化，以及数据库总会话是否仍有余量。若流量或实例数同时变化，不能把全部差异归因于参数。

空闲数设为零会不会禁止查询？

不会。它表示不保留空闲连接，不是禁止打开连接。业务仍可按需建连，但复用空间减少，需评估连接建立成本。

把MaxIdleConns设为MaxOpenConns最稳吗？

不一定。这样允许所有打开连接在空闲时继续保留，适合某些持续活跃负载，也可能增加低峰占用。它不是必须遵守的相等关系。

为什么调小闲置时间后InUse没有下降？

正在使用的连接不属于空闲部分。先检查事务是否结束、Rows 是否在不用时关闭、专用 Conn 是否调用 Close 归还。对查询期限，应使用支持取消的上下文并结合驱动行为处理。

默认两个空闲连接是不是太少？

当前标准库文档给出的默认空闲上限为2，并注明未来可能变化。够不够取决于并发模式和复用需求。持续低并发服务可能无需提高，频繁波峰场景则值得结合指标调整。