当前位置：首页 > 文章列表 > Golang > Go问答 > Go Tx.Stmt 复用预处理语句的生命周期

Go Tx.Stmt 复用预处理语句的生命周期

来源：17golang原创 2026-09-29 05:19:05 0浏览收藏

Tx.Stmt 的作用不是把原来的 *sql.Stmt 直接塞进事务，而是基于一个已经由 *sql.DB 准备好的语句，得到一个只属于当前事务的派生语句。派生语句在 Commit 或 Rollback 时关闭；原始 DB 级语句不随这个事务结束，仍由创建它的代码负责关闭。

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

先分清三个对象：DB 级语句、事务语句和连接

*sql.DB 是连接池句柄。由 DB.PrepareContext 返回的 *sql.Stmt 可以被多个 goroutine 并发使用，并在需要落到新的底层连接时自动为该连接完成准备。因此，“一个 DB 级 Stmt”并不等于“数据库服务器上永远只有一个物理预处理语句”。

*sql.Tx 则绑定到一条底层连接。调用 tx.StmtContext(ctx, baseStmt) 后，得到的是一个事务专用 *sql.Stmt，执行范围被限定在这个 Tx 内。事务结束后，这个派生对象也结束。

对象	绑定范围	何时失效	谁负责关闭
`DB.PrepareContext` 返回的 Stmt	DB 连接池	显式 Close 或 DB 生命周期结束	创建者
`Tx.StmtContext` 返回的 Stmt	当前事务及其连接	Commit、Rollback 或提前 Close	事务自动关闭，也可提前关闭
`Tx`	一条底层连接	Commit 或 Rollback	事务调用方

DB 级预处理语句与事务派生语句的静态绑定关系说明图 — 图1：DB 级 Stmt 属于连接池范围；每个 Tx 从它派生只属于本事务的 Stmt。

最小正确写法：先准备一次，再为每个事务派生

下面的模式适合一条更新语句会被许多事务重复使用的场景。重点是：原始语句在初始化阶段创建，事务内只保存派生语句，不把派生语句带出函数。

package order

import (
    "context"
    "database/sql"
    "fmt"
)

type Store struct {
    db         *sql.DB
    updateStmt *sql.Stmt
}

func NewStore(ctx context.Context, db *sql.DB) (*Store, error) {
    // 在 DB 级别准备一次，后续可以为多个事务派生专用语句。
    stmt, err := db.PrepareContext(ctx, `
        UPDATE orders
        SET status = ?
        WHERE id = ?
    `)
    if err != nil {
        return nil, fmt.Errorf("prepare update order: %w", err)
    }
    return &Store{db: db, updateStmt: stmt}, nil
}

func (s *Store) Close() error {
    // 原始 DB 级 Stmt 由创建者在服务退出时关闭。
    return s.updateStmt.Close()
}

func (s *Store) UpdateStatus(ctx context.Context, id int64, status string) error {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin transaction: %w", err)
    }
    // Commit 成功后再次 Rollback 会被忽略，统一兜住中途返回路径。
    defer tx.Rollback()

    // 派生语句只绑定当前事务；事务结束时 database/sql 会关闭它。
    txStmt := tx.StmtContext(ctx, s.updateStmt)
    if _, err := txStmt.ExecContext(ctx, status, id); err != nil {
        return fmt.Errorf("update order status: %w", err)
    }

    if err := tx.Commit(); err != nil {
        return fmt.Errorf("commit transaction: %w", err)
    }
    return nil
}

tx.StmtContext 本身不返回 error，但实际准备或执行问题会在后续操作中暴露。真正控制执行取消和超时的是 ExecContext、QueryContext 或 QueryRowContext 传入的上下文。官方文档明确说明，StmtContext 的上下文用于准备派生语句，不代替执行上下文。

生命周期的关键分界：事务结束只关闭派生对象

调用 Commit 或 Rollback 后，事务已结束，绑定在它上面的语句不能继续使用。此时不要缓存 txStmt，也不要把它返回给事务外代码。下一次事务应重新调用 Tx.StmtContext，得到新的事务专用对象。

与此同时，s.updateStmt 仍然属于 *sql.DB。它可以继续服务后续事务，直到应用关闭时显式调用 Close。这正是复用的核心：复用 SQL 准备入口，而不是复用某一个事务的状态。

原始 Stmt 与多个事务派生 Stmt 的生命周期边界说明图 — 图2：原始 Stmt 覆盖多个事务；每个派生 Stmt 只覆盖自己的 Tx，并随该 Tx 结束。

高并发场景下的取舍：能共享的是原始 Stmt

DB 级 Stmt 支持并发使用，适合放在长期存活的仓储或服务对象中。事务派生 Stmt 则属于单个事务，不应在不同事务之间共享。正确的并发模型是“一个长期原始 Stmt，多笔事务各自派生”，而不是“多个事务争用同一个 txStmt”。

高频重复 SQL：可以在初始化阶段准备 DB 级 Stmt，降低业务代码重复，并让驱动与连接池管理各连接上的准备状态。
事务内只执行一次：直接使用 tx.ExecContext 往往更简单；是否预处理还受数据库和驱动实现影响，不要只凭方法名假设一定更快。
事务内重复执行：如果语句只服务这一笔事务，tx.PrepareContext 也很直接；如果同一 SQL 同时用于事务外和许多事务，DB 级 Stmt 加 Tx.StmtContext 更便于集中管理。