Go database/sql 如何复用预处理语句并及时关闭

如果一条 SQL 在请求中反复执行，推荐把它准备成一个可复用的 sql.Stmt，而不是每次调用都重新 Prepare。最稳妥的边界是：由长期存活的 sql.DB 创建共享 Stmt，在服务关闭时调用 Close；事务里的语句则交给当前 sql.Tx 管理。这样既减少重复准备的开销，也不会把服务端准备语句资源一直留着。

先看负载：什么时候值得复用 PreparedStmt

“预处理语句更快”不是无条件结论。固定 SQL、参数不断变化、调用次数较多时，复用才能摊平准备成本。例如订单服务反复按用户 ID 查询状态，SQL 文本不变，只变化 id，适合提前准备。一次性执行的管理脚本则直接调用 ExecContext 更简单，不必为了复用增加长期资源。

还要把 sql.DB 看成连接池句柄，而不是一条永久连接。由 DB 创建的 Stmt 在 DB 存活期间可继续使用；当底层连接变化时，database/sql 会在需要时为新连接准备对应语句。因此应用不需要自己把 Stmt 绑定到某条池内连接。

DB 级 Stmt：准备一次，执行时只传参数

把准备动作放在仓储对象或服务初始化阶段，业务方法只负责传参。下面的示例使用 ? 占位符；PostgreSQL 驱动可能要求 $1，实际写法以驱动文档为准。

type UserRepo struct {
	// stmt 绑定固定查询，多个请求可以共享它。
	stmt *sql.Stmt
}

func NewUserRepo(ctx context.Context, db *sql.DB) (*UserRepo, error) {
	stmt, err := db.PrepareContext(ctx,
		"SELECT id, name FROM users WHERE id = ?")
	if err != nil {
		// 准备失败时不要返回一个半初始化的仓储对象。
		return nil, fmt.Errorf("prepare user query: %w", err)
	}
	return &UserRepo{stmt: stmt}, nil
}

func (r *UserRepo) Find(ctx context.Context, id int64) (User, error) {
	var u User
	// 执行阶段使用调用方的 context，让取消和超时能够传到驱动。
	err := r.stmt.QueryRowContext(ctx, id).Scan(&u.ID, &u.Name)
	if err != nil {
		return User{}, err
	}
	return u, nil
}

func (r *UserRepo) Close() error {
	// 服务退出时由上层统一调用，释放 Stmt 持有的数据库资源。
	return r.stmt.Close()
}

这里的关键不是把 SQL 写成全局变量，而是让“准备一次、重复执行、明确关闭”形成完整生命周期。sql.Stmt 可以被多个 goroutine 并发使用，但仍应在构造失败时立即处理错误，在服务停止时调用仓储的 Close。

局部语句和事务语句，关闭位置不一样

如果 Stmt 只在一个函数里使用，关闭责任可以紧跟在成功 Prepare 之后。若语句要参与事务，不要直接拿 DB 级 Stmt 当作事务对象使用；用 tx.StmtContext 得到当前事务专属的 Stmt，或者直接调用 tx.PrepareContext。

func AddAudit(ctx context.Context, db *sql.DB, shared *sql.Stmt, uid int64) error {
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	// Commit 成功后不会再需要回滚；失败路径仍有兜底清理。
	defer tx.Rollback()

	// 从 DB 级语句派生当前事务使用的语句，避免跨事务持有连接。
	txStmt := tx.StmtContext(ctx, shared)
	defer txStmt.Close()
	if _, err := txStmt.ExecContext(ctx, uid, "login"); err != nil {
		return fmt.Errorf("insert audit log: %w", err)
	}
	// 只有提交成功，事务内的写入才对外生效。
	return tx.Commit()
}

事务提交或回滚后，事务专属 Stmt 就不应再使用。普通查询若返回 *sql.Rows，还要在对应函数里关闭 Rows；Stmt 关闭并不会替你处理已经拿到的结果集。

常见坑：反复 Prepare、错用 context 和忘记 Close

最后做一次落地检查：固定 SQL 是否真的高频；Prepare 错误是否会阻止半成品上线；执行方法是否携带调用方 context；服务退出是否关闭共享 Stmt；事务是否只使用自己的语句；驱动的占位符是否正确。满足这六项，复用和释放通常就不会互相冲突。

相关问题

sql.Stmt 能被多个 goroutine 共用吗？

可以。由 DB 创建的 Stmt 支持并发使用，但仍要让它跟随 DB 的生命周期，并在不再需要时关闭。

每次调用都 defer stmt.Close 会不会更安全？

只适合局部短生命周期语句。若目标是复用，就不要在每次业务调用里重新 Prepare，而应在外层创建一次、在外层关闭。

PrepareContext 的 context 会约束后续查询吗？

不会。它用于准备动作；查询或执行要使用 Stmt.QueryContext、Stmt.QueryRowContext 或 Stmt.ExecContext 传入执行阶段的 context。