当前位置：首页 > 文章列表 > Golang > Go问答 > Go 事务隔离级别设置未生效的驱动边界

Go 事务隔离级别设置未生效的驱动边界

来源：17golang原创 2026-09-29 04:53:23 0浏览收藏

在 Go 里把 sql.TxOptions{Isolation: ...} 传给 DB.BeginTx，并不等于 database/sql 已经替你向所有数据库执行了同一种隔离级别命令。它做的是把一个标准化请求交给当前驱动；真正怎样映射、数据库支持哪些级别、该设置落在会话还是下一笔事务，都是驱动与数据库共同决定的。

如果 BeginTx 已成功，但你看到的会话变量仍是默认值，先不要断言隔离级别失效。先核对驱动实现，再区分“会话默认值”和“下一笔事务特征”，最后用并发事务行为验收。

我第一次遇到这个问题时，注意力一直放在 TxOptions 的写法上。后来沿着接口往下看才发现，真正需要排查的是三层边界：Go 标准库有没有把选项传下去、驱动有没有正确翻译、数据库如何解释这条命令。

本文依据的官方入口是 https://pkg.go.dev/database/sql、https://pkg.go.dev/database/sql/driver、https://github.com/go-sql-driver/mysql 和 https://dev.mysql.com/doc/refman/8.4/en/set-transaction.html。

先确认 TxOptions 只是传给驱动的请求

database/sql 定义了统一的 IsolationLevel，也明确说明：驱动不支持某个非默认隔离级别时，BeginTx 会返回错误。这里的重点是“驱动支持”，不是标准库为所有数据库实现了同一套事务语句。

opts := &sql.TxOptions{
    // 请求串行化级别，是否支持由驱动和数据库决定。
    Isolation: sql.LevelSerializable,
    // 本例仍允许写入；只读能力同样要由驱动处理。
    ReadOnly: false,
}

tx, err := db.BeginTx(ctx, opts)
if err != nil {
    return fmt.Errorf("begin serializable transaction: %w", err)
}
defer func() {
    // 业务提前返回时回滚；提交成功后这里会返回 sql.ErrTxDone。
    _ = tx.Rollback()
}()

LevelDefault 还有一层不同含义：它让驱动或数据库使用默认级别。把它和显式的 LevelRepeatableRead 混为一谈，会让排查变得很绕。前者没有要求驱动切换级别，后者要求驱动识别并执行对应映射。

Go TxOptions 穿过 database/sql 到数据库驱动的静态边界结构 — 图1：TxOptions、database/sql、ConnBeginTx 与数据库事务特征的静态结构说明图；它展示责任边界，不是运行截图或执行顺序证明。

沿 BeginTx 到 ConnBeginTx 检查驱动映射

驱动如果实现了 driver.ConnBeginTx，就会收到 driver.TxOptions。官方接口契约要求它检查 Isolation 和 ReadOnly：不能支持非默认值时应返回错误，而不是悄悄按默认级别开始事务。

type ConnBeginTx interface {
    // 驱动在这里接收标准库传下来的事务选项。
    BeginTx(ctx context.Context, opts driver.TxOptions) (driver.Tx, error)
}

排查时应锁定项目实际使用的驱动模块和版本，再去看该版本的 BeginTx 实现。以当前 go-sql-driver/mysql 源码为例，它会先把非默认隔离级别映射成 MySQL 能识别的名称，执行 SET TRANSACTION ISOLATION LEVEL ...，然后开始事务。换成 PostgreSQL、SQL Server 或 SQLite 驱动，映射策略和支持集合都可能不同。

这一步常见的误区是只查数据库文档，不查驱动；或者只查驱动最新版，却没有核对 go.mod 中实际锁定的版本。驱动升级也不是纯粹的“越新越好”，应该先阅读变更记录并跑回归测试。

区分会话默认值与下一笔事务的作用域

MySQL 是“看起来没生效”最典型的场景之一。官方文档把事务特征分成全局、会话和下一笔事务三个作用域。不带 SESSION 或 GLOBAL 的 SET TRANSACTION ISOLATION LEVEL ... 只影响下一笔事务，事务结束后仍回到会话默认值。

因此，在事务里查询 @@SESSION.transaction_isolation，看到的仍可能是会话默认值。这条查询回答的是“这个连接后续事务默认采用什么”，不是“驱动刚给当前这笔事务设置了什么”。把两者当成同一个问题，就会得到错误结论。

-- 这条语句读取会话默认值，不应单独用来断言当前事务的级别。
SELECT @@SESSION.transaction_isolation;

-- 不带 SESSION 的设置只约束下一笔事务。
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

还有一个经常被忽略的边界：连接池会复用物理连接，但 sql.Tx 在生命周期内绑定一个连接。不要在 db.ExecContext 上设置会话状态，再假定随后 db.BeginTx 一定取得同一条物理连接；如果确实需要连接级操作，应显式取得 sql.Conn，并把相关操作放在同一个连接生命周期内。

MySQL 全局会话与下一笔事务隔离级别作用域的静态关系 — 图2：MySQL 事务隔离作用域的静态关系图；会话默认值与下一笔事务特征属于不同边界，这不是数据库控制台截图。

把排查改成驱动能力和事务语义两道门禁

我现在会先过两道门禁，而不是马上改 SQL。第一道是“能力门禁”：确认驱动版本、ConnBeginTx 实现、目标级别映射以及 BeginTx 返回错误。第二道是“语义门禁”：确认数据库对该命令的作用域、事务开始时机以及验证查询真正表达的含义。

记录 go.mod 中的驱动模块和版本，不用“我记得这个驱动支持”代替证据。
检查 BeginTx 的错误，禁止忽略后继续执行业务 SQL。
确认驱动把 Go 的枚举映射成哪条数据库命令。
确认数据库命令影响全局、会话、下一笔事务还是当前事务。
验证语句必须和所测作用域一致；会话默认变量只能证明会话默认值。

如果使用 ORM，还要再加一层：确认 ORM 的事务入口是否真的把 TxOptions 传到 database/sql。某些封装提供了同名配置，但生效时机可能在建连、会话初始化或事务开始，不应仅凭字段名称推断。

用最小业务实验验收隔离行为

隔离级别的最终证据不是一条默认变量，而是目标数据库定义的并发可见性。可以准备两条独立连接，使用一张专门的测试表，让事务 A 读取同一行两次，事务 B 在两次读取之间提交更新，再观察事务 A 的第二次读取是否符合目标隔离级别。这个实验必须在隔离环境执行，不能对生产数据尝试。

func beginSerializable(ctx context.Context, db *sql.DB) (*sql.Tx, error) {
    tx, err := db.BeginTx(ctx, &sql.TxOptions{
        // 明确要求串行化，不使用驱动或数据库默认值。
        Isolation: sql.LevelSerializable,
    })
    if err != nil {
        return nil, fmt.Errorf("driver rejected serializable isolation: %w", err)
    }
    return tx, nil
}

实验记录至少包含驱动版本、数据库版本、事务 A 和 B 的操作、每个操作发生的连接、阻塞或错误类型。不要只写“第二次读不一样，所以失败”，因为不同数据库对快照、锁等待和串行化冲突的实现并不相同。验收条件应该来自目标数据库的官方隔离级别说明。