Go SQL 查询取消：让慢查询跟着请求一起停

入口请求已经超时，但 SQL 仍在数据库里跑，这种情况会继续占用连接池和数据库资源。database/sql 提供的 Context API 可以把取消信号传到查询层。

QueryContext 的意义

QueryContext 接收 context，当 deadline 到达或请求取消时，驱动有机会取消查询并释放连接。具体行为取决于驱动，但使用 Context API 是必要前提。

事务也要有 context

BeginTx 可以传入 context。长事务如果不受控，会持有锁和连接，放大并发问题。事务内部的每条查询也应该使用同一个 ctx。

取消后要正确收尾

Rows 必须关闭，事务失败要 rollback。不要因为 context 超时就跳过清理逻辑。

生产场景

适用于请求链路里的查询、写入和事务操作。用户已经取消或入口超时后，SQL 继续执行会占用连接、锁和数据库 CPU。

关键指标

• SQL context 取消次数与慢查询数量
• Rows 未关闭导致的连接占用
• 事务超时、回滚和锁等待分布

常见误区

• 请求链路中混用 Query 与 QueryContext
• 事务超时后没有 rollback
• 驱动不支持取消时仍认为问题已经解决

落地建议

建议统一封装 repository 层，禁止请求路径使用无 Context 的 API。对关键 SQL 添加 trace id 和耗时日志，取消后仍要完整执行 Rows Close、Rollback 等清理动作。

代码示例

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

if _, err := tx.ExecContext(ctx, updateSQL, args...); err != nil {
    return err
}
return tx.Commit()

上线检查

• 禁止在请求链路中使用 Query/Exec 替代 Context 版本。
• Rows 和 Tx 都有清理逻辑。
• 慢查询日志能关联 trace/request id。