Go database/sql Rows提前退出后的连接释放排查

Go 里用 database/sql 查询多行数据时，最容易被忽略的不是 QueryContext，而是“只取到前几行就返回”的路径。完整遍历时，Next 走到末尾可能触发自动关闭；但命中数量上限、扫描失败或业务判断提前结束时，代码必须主动关闭 Rows。稳妥做法是：查询后立刻安排 defer rows.Close() 作为兜底，提前退出处再显式关闭，并分别保留 Scan、Close 和 Rows.Err 的错误。

先把 Rows 的生命周期收拢到一个函数

Rows 是查询结果集的游标，底层可能仍占用驱动资源。它不等同于已经装进内存的切片。尤其是列表预览、自动补全、权限检查这类只需要前几行的场景，break 只会离开循环，不会替你表达“结果集现在可以结束了”。

因此，查询、扫描、上限判断和关闭最好放在一个短函数里。这样调用方拿到的是已经完成资源收尾的切片，而不是一个仍影响连接池的中间对象。

用一个短函数处理 limit 和提前返回

下面的写法保留三种信息：当前行的扫描错误、关闭结果集时的错误，以及迭代阶段的错误。示例只表达处理方式，不依赖某个具体数据库驱动。

func loadNames(ctx context.Context, db *sql.DB, limit int) (names []string, err error) {
    if limit 

这里没有把 defer 写在一个长生命周期的批量循环外，而是让每次查询在函数结束时释放。显式 Close 先处理提前退出；defer 仍然负责扫描错误、未来新增 return 分支等意外路径。Rows.Close 是幂等的，双保险不会因为重复关闭改变 Rows.Err 的结果。

把 Close、Scan 和 Rows.Err 分成三类证据

排查连接释放问题时，不要只看最后一个 err。三类错误代表不同边界：

“没有行”不是错误：如果循环一次都没有进入，且 rows.Err() 为 nil，应把它当作空结果处理。相反，Next 返回 false 可能是驱动在读取下一行时失败，只有检查 Err 才能确认。

哪些方案适合，哪些方案不适合

需要完整读完结果集时，常规的 defer rows.Close() 加循环末尾 rows.Err() 就够用；只取前 N 行或遇到业务条件就停时，选择“短函数 + 显式 Close + Err 检查”。不要把 SetMaxOpenConns 调大当成修复，它只能延后连接池耗尽，不能替代结果集生命周期管理。

相关问题

Rows.Close 调用两次会报错吗？

官方文档将 Close 定义为幂等操作。常见的“显式关闭 + defer 兜底”可以保留，但业务上仍应让关闭点清晰，避免把真正的错误吞掉。

Rows.Err 能代替 Rows.Close 吗？

不能覆盖提前退出。完整遍历到没有更多结果集时可能自动关闭，此时检查 Err 足够；只读部分结果时仍应主动调用 Close。

应该把 db.Close 写在每次查询后吗？

不应该。sql.DB 是连接池句柄，通常由应用生命周期管理；每次查询需要管理的是本次 Rows，而不是关闭整个数据库对象。

最终检查可以压缩成四项：查询失败立即返回；拿到 Rows 后马上安排兜底关闭；提前退出前显式 Close；循环结束后用 Rows.Err 判定尾部状态。线上若仍看到连接池等待升高，再结合 DB.Stats 和具体 driver 日志定位，而不是先放大连接上限。