Go database/sql 忘记 Rows.Close 为什么会拖垮连接池：事务收尾与排查

线上接口的数据库耗时突然变长，应用CPU占用却没升高，最容易被漏掉的一条故障线索是：查询返回的 Rows 没有及时关闭。database/sql 本身是帮应用维护连接池的组件，但一份还在枚举数据、或者忘了收尾的结果集，会一直占着绑定的数据库连接不归还；如果这段逻辑还跑在事务里，后续的相关操作也会被死死绑定在这条被占用的连接上。

漏关Rows本质上没有释放绑定的数据库连接，大量连接被静默占用后新请求拿不到可用连接，就会在连接池外层排队，最终拖慢所有关联接口。

为什么一次漏关 Rows，会变成连接池排队

先把几个核心对象的依赖关系拆解开：sql.DB 代表一组可复用的长连接；调用 QueryContext 后得到的 *sql.Rows 代表一次结果集读取的生命周期；调用 BeginTx 得到的 *sql.Tx 则会直接绑定一条物理连接，直到提交或者回滚完成才会归还。

假设连接池上限设为20，刚好20个请求都拿到结果集之后就直接提前返回，忘了关闭对应的 Rows，第21个请求不会凭空得到第21条空闲连接，只能在连接池的队列里排队等资源。应用日志里通常只会看到“数据库调用变慢”的记录，但查数据库本身的监控未必能看到高CPU占用的情况。

这也是为什么只盯着SQL慢查询往往找不到根因：接口变慢是因为在等空闲连接，不一定是SQL本身执行耗时高。

先用 DBStats 判断是执行慢还是等连接

在复现问题或者告警采样的节点，打印一组轻量的连接池指标。下面的数字只是示例，核心是观察这些指标的变化是否和故障时间线完全对齐：

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,
)

DBStats 是应用侧的直接观测证据，不能完全替代数据库监控的结论。但它可以快速帮你判断，要不要先沿着“连接有没有正常归还”这条线索往下排查。

Rows 的正确边界：拿到结果就安排关闭

多行查询的安全写法，不是等遍历完所有行之后才想起调用关闭，而是在确认查询没有返回错误之后，立刻安排关闭逻辑：

rows, err := db.QueryContext(ctx, `SELECT id, state FROM jobs WHERE state = ?`, "ready")
if err != nil {
    return err
}
defer rows.Close()

for rows.Next() {
    var id int64
    var state string
    if err := rows.Scan(&id, &state); err != nil {
        return err
    }
    // 只把当前行复制到业务对象，不把 rows 带出这个函数。
}
if err := rows.Err(); err != nil {
    return err
}
return nil

defer rows.Close() 能覆盖所有提前返回的路径，包括扫描失败、业务校验失败、上下文被取消这些场景。就算循环自然走完所有行，结果集很多驱动也会做自动关闭，但显式加关闭逻辑能把中途返回的所有场景都覆盖到；同时结束后仍然要检查 rows.Err() 的返回值，不然枚举数据的过程中网络或者驱动抛出的异常很可能被直接吞掉。

事务里为什么还要区分 Rows.Close 和 Rollback

事务收尾和结果集收尾是两个完全独立的责任。一个标准的小型事务函数，完全可以把回滚作为默认兜底逻辑，等所有业务动作都执行成功之后再调用提交：

tx, err := db.BeginTx(ctx, nil)
if err != nil {
    return err
}
defer tx.Rollback()

rows, err := tx.QueryContext(ctx, `SELECT id FROM jobs WHERE state = ?`, "ready")
if err != nil {
    return err
}
defer rows.Close()

for rows.Next() {
    var id int64
    if err := rows.Scan(&id); err != nil {
        return err
    }
    // 根据 id 做同一事务内的校验或更新。
}
if err := rows.Err(); err != nil {
    return err
}
if err := tx.Commit(); err != nil {
    return err
}
return nil

这里写两次关闭动作 defer 不是多余操作：Rows.Close 负责结束结果集的生命周期；Rollback 负责确保任意错误分支都不会把事务挂起悬停在数据库里。提交操作成功执行之后，后续再调用回滚会直接变成无效操作，不需要额外写分支去判断要不要调用回滚。

真正要避免的做法是把 Rows 直接返回给更上层的调用方，让外层逻辑决定什么时候关闭结果集。结果集的生命周期应该尽量收窄变短，尤其不能在持有事务连接的间隙，去调用外部网络请求、发送消息或者跑长时间的业务计算。

一次复现：把连接池耗尽拆成三个检查点

要确认根因，可以先把连接池的上限临时调小到2或者4，再用并发请求触发问题。别一上来就把连接上限调大，那只会把连接泄漏的问题推迟到更高流量场景才暴露，根本解决不了根因。

1. 记录请求开始、拿到 Rows、关闭 Rows、事务提交或回滚的几个关键时间点。
2. 同时采样 InUse、Idle、WaitCount 和 WaitDuration，确认排队等待是不是从打开结果集之后才开始的。
3. 给查询函数增加超时和退出日志，确认请求被取消之后能不能正常走到关闭结果集和事务回滚的逻辑。

如果关闭结果集之后 InUse 很快下降、Idle 回升，新的请求也不再排队等待，那修复方向就非常明确。反过来如果指标没有任何变化，就需要继续排查连接泄漏之外的可能性，比如长事务、没关闭的预处理语句、驱动层阻塞或者数据库侧的锁等待。

规模化场景下的取舍：短事务、短结果集、可观测收尾

连接池不是调得越大越好，池的上限需要结合数据库允许的总并发数、单条请求的查询平均耗时、应用实例数量一起计算。十个实例每个都开20条连接的话，数据库侧看到的总并发上限可能已经到了200。

实际落地的时候可以把三条规则直接放进代码评审的检查清单里：

• 任何 Query 或 QueryContext 调用成功后，下一行立刻安排 Rows.Close。
• 任何 Begin 或 BeginTx 调用成功后，都有默认 Rollback 兜底，并且明确写出成功提交的分支点。
• 不要在事务和结果集存活的周期内，调用外部HTTP接口、等待人工输入或者执行不可控的批量处理逻辑。

常见问题

QueryRow 也需要手动 Close 吗？

QueryRow 返回的是 *sql.Row，使用方式和显式返回的 *sql.Rows 不一样。重点是及时调用 Scan，处理返回的错误；不用为了统一格式强行把它当成标准Rows对象来操作。

rows.Next 返回 false 就不用检查 Err 了吗？

仍然要检查 rows.Err()。遍历结束返回false可能代表数据正常读完，也可能是驱动在读取数据的过程中遇到了异常中断。

把 MaxOpenConns 调大能解决吗？

它可能暂时降低排队的概率，但根本修复不了结果集或者事务没有正常收尾的问题；多实例部署放大之后，还可能把数据库侧的总连接数推过最大限制。

为什么连接池指标正常，接口还是慢？

这时要把视线转向SQL执行逻辑、锁等待、数据库负载、网络往返或者应用内其他中间件的队列。DBStats 只能证明应用连接池这一层的状态没问题。

最后核对一条完整链路

遇到“数据库调用突然变慢”的故障时，先确认请求是不是在等连接，再定位哪段代码路径持有 Rows 或者 Tx 没释放，最后才决定要不要调整连接池的大小。修复后的验收不能只看单次请求能跑通，要确认 Rows.Close、rows.Err、Commit/Rollback 所有错误分支都能正常走到释放资源的逻辑，高并发场景下 WaitCount 也不会持续往上爬升。