Go database/sql Context 取消后为什么连接仍未释放

Go 的 database/sql 在 Context 取消后并不承诺立刻销毁底层 TCP 连接。更常见的结果是：查询被中止，连接回到 sql.DB 的空闲池，等待下一次复用，所以 OpenConnections 仍然大于零并不能直接证明泄漏。

官方文档：https://pkg.go.dev/database/sql#DB.QueryContext

先判断：连接存在不等于连接没有释放

sql.DB 是并发安全的连接池句柄。一次查询结束后，连接通常从 InUse 回到 Idle，只有空闲连接超出策略、连接过期或驱动报告连接不可用时，池才会关闭它。因此取消后看到数据库端连接短时间仍在，首先应问的是“它是否回池”，而不是“为什么没有立刻断开”。

把取消信号和结果集的释放路径写完整

最容易遗漏的是只写了 cancel()，却没有关闭返回的 Rows。取消 Context 只表达“这项工作不再需要”，结果集仍应有明确的关闭路径。标准库文档也建议在拿到 Rows 后安排 defer rows.Close()，循环结束后再查看 rows.Err()。

func queryUsers(parent context.Context, db *sql.DB) error {
	// 超时由当前查询拥有，函数返回时释放定时器等 Context 资源。
	ctx, cancel := context.WithTimeout(parent, 3*time.Second)
	defer cancel()

	rows, err := db.QueryContext(ctx, `SELECT id, name FROM users WHERE enabled = ?`, true)
	if err != nil {
		// 取消或超时可能在拿到 Rows 前发生，先返回即可。
		return err
	}
	defer rows.Close() // 提前返回、Scan 出错时也归还结果集资源。

	for rows.Next() {
		var id int64
		var name string
		if err := rows.Scan(&id, &name); err != nil {
			return err
		}
	}
	// Next 结束不代表没有错误，取消后的驱动错误要从这里读取。
	return rows.Err()
}

这个模式解决的是 Go 层的释放责任：Context 有 cancel，Rows 有 Close，迭代结果有 Err。它不能替驱动完成数据库协议层的中断。

驱动是否支持取消，决定连接会不会长期卡在 InUse

database/sql/driver 的 QueryerContext 是可选接口，但一旦驱动实现它，就必须遵守 Context 超时和取消并返回。如果驱动没有实现，会走旧的 Queryer 或准备语句的回退路径；这不等于底层数据库一定能被中断。于是会出现两种看似相同的现象：Go 请求已经返回超时，但底层调用仍未结束，连接继续处于使用中。

排查时把“取消返回错误”和“连接已可复用”分开记录。先看 rows.Err() 是否为 context deadline exceeded 或 context canceled，再连续采样 DB.Stats()。若 InUse 在驱动完成前持续占满，而新查询在 SetMaxOpenConns 限制下排队，问题更接近驱动取消能力或数据库服务端执行未终止，而不是简单漏写一行 Close。

用指标和连接类型做最后确认

可以把连接池统计放进临时诊断日志，但不要把一次采样当成结论：

func logPoolState(db *sql.DB) {
	stats := db.Stats()
	// InUse 关注正在占用的连接，Idle 关注已经回池但仍保持打开的连接。
	log.Printf("open=%d in_use=%d idle=%d wait_count=%d", 
		stats.OpenConnections, stats.InUse, stats.Idle, stats.WaitCount)
}

若代码通过 db.Conn(ctx) 取得专用 sql.Conn，还要在使用后调用 conn.Close()，因为它不会像普通 db.QueryContext 那样仅由一次操作结束来完成专用连接的归还。事务则应在取消路径执行 Rollback，不要只等待 Context 自动结束。

最终检查清单可以压缩成四项：查询方法是否带 Context；创建的 Context 是否调用 cancel；返回 Rows 后是否 Close 并检查 Err；专用连接和事务是否分别 Close、Rollback。只有这些都满足，仍然看到 InUse 长时间不降，才值得继续追踪驱动实现和数据库服务器端取消行为。

相关问题

取消 Context 后为什么 Idle 连接还在？

Idle 表示连接已归还连接池但尚未物理关闭，池保留它是为了复用。需要观察空闲时间和连接池策略，不要要求每次取消都断开。

只调用 cancel 不调用 rows.Close 可以吗？

不建议。Context 取消与 Rows 资源关闭是两条责任链，提前返回、Scan 出错或驱动行为不同都可能让 Close 缺失。

怎么确认是驱动没有响应取消？

将 rows.Err、InUse、WaitCount 和数据库端执行状态放在同一时间窗口对照；若 Go 层已返回但连接持续占用，优先检查驱动的 QueryContext 实现和数据库取消协议。