Go sql.Stmt复用预编译查询时的生命周期管理方法

我在把一条高频查询从“每次请求都 Prepare”改成复用 sql.Stmt 时，最先遇到的不是 SQL 写错，而是关闭责任变得模糊：Stmt 到底跟着请求结束，跟着事务结束，还是跟着整个应用结束？更稳妥的做法是先看它从谁身上创建。

如果 Stmt 由 *sql.DB 的 PrepareContext 创建，就把它视为应用级资源：初始化时创建，服务停止时关闭，业务请求只负责传参和执行。由 Conn 或 Tx 创建的 Stmt 则绑定到单连接或单事务，不能跨生命周期长期缓存。

官方地址：https://pkg.go.dev/database/sql

一、先看Stmt是在哪个对象上创建的

database/sql里，DB代表连接池，Conn代表从池中取出的专用连接，Tx代表事务。三者都能参与预编译，但生命周期含义不同。官方文档说明，DB级Stmt可以在多个底层连接上复用；Conn级或Tx级Stmt则会固定在单个底层连接上。

二、把DB级Stmt放进应用初始化层

高频、结构稳定的查询适合在仓储对象初始化时准备。下面的结构把 Stmt 的所有权交给仓储对象：构造失败直接返回，正常关闭时先关Stmt，再由更上层关闭DB。示例只展示生命周期组织，不依赖某个具体驱动。

type UserStore struct {
	db       *sql.DB
	findByID *sql.Stmt
}

func NewUserStore(ctx context.Context, db *sql.DB) (*UserStore, error) {
	// DB级Stmt由仓储对象拥有，创建一次后供多个请求复用。
	stmt, err := db.PrepareContext(ctx, `SELECT id, name FROM users WHERE id = ?`)
	if err != nil {
		// 初始化失败时不返回半成品，避免调用方忘记清理已分配资源。
		return nil, fmt.Errorf("prepare find user: %w", err)
	}
	return &UserStore{db: db, findByID: stmt}, nil
}

func (s *UserStore) Close() error {
	// 关闭点与NewUserStore的所有权保持一致，不放到单次请求中。
	return s.findByID.Close()
}

func (s *UserStore) Find(ctx context.Context, id int64) (string, error) {
	var name string
	// 每次执行只传请求参数，Stmt本身仍由仓储对象长期持有。
	err := s.findByID.QueryRowContext(ctx, id).Scan(&name)
	if err != nil {
		return "", err
	}
	return name, nil
}

这里的关键不是把Stmt做成全局变量，而是让“创建者负责关闭”成为可追踪的所有权规则。若服务支持热重载，先停止接收新请求，再等待调用方退出，最后调用仓储的 Close；不要在仍有并发查询时强行替换同一个指针。

三、查询型Stmt要把Rows边界收干净

QueryContext 返回的 *sql.Rows 也需要关闭，且循环结束后要检查 Rows.Err。单行查询可以用 QueryRowContext，它把读取第一行和关闭剩余结果的工作收敛到 Scan；多行查询则要显式处理结果集。

func (s *UserStore) ListNames(ctx context.Context, ids []int64) ([]string, error) {
	rows, err := s.findByID.QueryContext(ctx, ids[0])
	if err != nil {
		return nil, err
	}
	defer rows.Close() // 结果集属于本次调用，不能交给共享Stmt长期持有。

	var names []string
	for rows.Next() {
		var name string
		if err := rows.Scan(&name); err != nil {
			return nil, err
		}
		names = append(names, name)
	}
	if err := rows.Err(); err != nil {
		// 尾部网络或驱动错误可能在Next返回false后才出现。
		return nil, err
	}
	return names, nil
}

示例中的参数只是为了聚焦资源边界；真实的批量查询应根据驱动占位符拼接或使用合适的批量接口，不能把用户输入直接拼进SQL。Stmt复用解决的是预编译对象的生命周期，不会自动解决SQL参数数量、索引设计或大结果集内存问题。

四、Conn级和Tx级Stmt不能照搬DB级用法

需要会话变量、临时表或事务一致性时，才有理由把Stmt绑定到 Conn 或 Tx。Conn级Stmt不能在Conn归还连接池后继续使用；Tx级Stmt在事务提交或回滚后也不再是可用的业务对象。若已有DB级Stmt，只想在事务中执行，可以用 tx.StmtContext(ctx, stmt) 得到事务范围的使用方式，而不是把事务Stmt缓存到全局。

func UpdateInTx(ctx context.Context, db *sql.DB, stmt *sql.Stmt, id int64) error {
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer tx.Rollback() // 提交成功后Rollback会被忽略，异常路径仍能释放事务。

	// 复用DB级Stmt的SQL形状，但让这次执行落在当前事务连接上。
	if _, err := tx.StmtContext(ctx, stmt).ExecContext(ctx, id); err != nil {
		return err
	}
	return tx.Commit()
}

五、用关闭清单处理重载与停机

我最后会把关闭责任写成一张清单，而不是依赖调用者记忆：第一，记录谁创建了DB级Stmt；第二，记录谁拥有DB；第三，停机时先阻止新请求，再等待正在执行的查询，随后关闭Stmt和DB；第四，事务内临时Stmt只在事务函数内存在。这样排查“Stmt已经关闭”“事务结束后执行失败”时，能先回到对象归属，而不是盲目重建连接池。

把 sql.Stmt 当成“带所有权的预编译资源”，文章标题中的复用才有实际意义：DB级复用服务于稳定查询，Conn级和Tx级复用服务于局部一致性，而Rows和事务必须在更短的调用范围内收口。

常见问题

DB级Stmt能被多个goroutine同时使用吗？

可以，官方文档明确说明Stmt支持并发使用；但调用方仍要正确处理每次查询返回的Rows、错误和取消。

每个请求都Prepare再defer Close有什么问题？

它把重复的准备开销和资源管理放进请求热路径，容易让高并发下的连接与服务端预编译资源变得难以观察。固定SQL更适合在应用初始化层复用。

关闭Stmt会不会立刻打断正在执行的查询？

不要把Close当作并发取消机制。停机流程应先停止接收新请求并等待在途调用，再关闭拥有者；真正的查询取消应通过带取消信号的Context处理。