Go问答：sql.TxOptions Isolation事务隔离级别设置后为什么看不到变化怎样完成一个可复用的最小示例

我第一次给事务加上 sql.TxOptions{Isolation: ...} 时，最容易产生的错觉是：只要把字段写进去，下一条查询就应该立刻返回不同结果。实际上，Isolation 约束的是并发事务之间能看到什么、何时能看到，以及冲突如何处理；如果只有一个事务、没有竞争读写，设置前后看起来完全一样是正常的。

解决“设置后看不到变化”的关键，是把单次查询改成两个事务的并发观察，并确认驱动确实支持你传入的隔离级别。database/sql 负责传递事务选项，具体语义仍由驱动和数据库实现。

官方参考：https://pkg.go.dev/database/sql

• 旧写法：直接调用 Begin()，实际使用数据库或驱动默认隔离级别。
• 新写法：用 BeginTx(ctx, &sql.TxOptions{Isolation: level}) 显式表达意图。
• 观察方式：准备事务A与事务B，让它们在同一份数据上产生并发读写，再比较结果。
• 边界判断：不支持的级别、驱动映射差异和连接会话设置，都可能让“预期变化”不成立。

先把“没有变化”拆成三个问题

迁移这类代码时，我会先问三个问题：隔离级别有没有传到事务入口？当前场景有没有并发读写？驱动和数据库是否支持这个级别？这三个问题分别对应配置、观察条件和实现边界，不能只看一条查询结果。

如果代码只是打开连接、启动一个事务、执行一条查询、马上提交，那么它没有对照组，也没有竞争者。即使隔离级别已经生效，读到的仍可能是同一份已提交数据，所以不能据此判断 Isolation 没有生效。

从隐式默认值迁移到 BeginTx

旧代码常见的写法是 db.Begin()。它适合不需要表达隔离意图的简单事务，但当业务依赖某种并发可见性时，默认值会把真正的行为藏在驱动和数据库配置里。迁移时可以把隔离级别集中在一个函数中，避免每个调用点各写一套提交和回滚逻辑。

package txdemo

import (
    "context"
    "database/sql"
)

// BeginWithIsolation 统一创建事务，调用方只需要关心隔离级别和业务 SQL。
func BeginWithIsolation(ctx context.Context, db *sql.DB, level sql.IsolationLevel) (*sql.Tx, error) {
    // BeginTx 会把隔离选项交给 database/sql，再由驱动映射到数据库会话。
    return db.BeginTx(ctx, &sql.TxOptions{Isolation: level})
}

// ReadInTx 展示事务内查询；真实业务还应根据结果决定提交或回滚。
func ReadInTx(ctx context.Context, db *sql.DB, level sql.IsolationLevel) error {
    tx, err := BeginWithIsolation(ctx, db, level)
    if err != nil {
        // 驱动不支持该级别时，应保留错误并让上层决定降级或失败。
        return err
    }
    defer tx.Rollback() // 提交成功后 Rollback 只会返回已结束状态，作为兜底清理。

    var value string
    if err := tx.QueryRowContext(ctx, "SELECT value FROM settings WHERE id = ?", 1).Scan(&value); err != nil {
        // 查询失败时由 defer 回滚，避免把半完成事务留在连接上。
        return err
    }
    _ = value // 示例只展示事务入口；业务代码在这里使用读取结果。
    return tx.Commit()
}

这里最重要的不是函数名，而是两个迁移动作：用 BeginTx 传入选项，并把“不支持该级别”的错误当成真实分支处理。不要把错误吞掉后再假设数据库已经按目标隔离级别运行。

用两个事务观察隔离差异

要让隔离级别变得可观察，需要至少两个事务。事务A修改一行但暂不提交，事务B在同一时段读取或尝试修改同一行，然后根据数据库允许的并发行为记录结果。测试重点不是强行得到某个固定字符串，而是验证业务关心的读写边界。

func OpenPair(ctx context.Context, db *sql.DB, level sql.IsolationLevel) (*sql.Tx, *sql.Tx, error) {
    // 两个事务必须分别调用 BeginTx，才能形成可观察的并发关系。
    txA, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: level})
    if err != nil {
        return nil, nil, err
    }
    txB, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: level})
    if err != nil {
        // 第二个事务创建失败时及时释放第一个事务占用的连接。
        _ = txA.Rollback()
        return nil, nil, err
    }
    return txA, txB, nil
}

func Observe(ctx context.Context, txA, txB *sql.Tx) error {
    // A 先写但不提交，B 再读；具体结果由驱动和数据库的隔离语义决定。
    if _, err := txA.ExecContext(ctx, "UPDATE accounts SET balance = balance - ? WHERE id = ?", 10, 1); err != nil {
        _ = txA.Rollback()
        _ = txB.Rollback()
        return err
    }
    var balance int64
    if err := txB.QueryRowContext(ctx, "SELECT balance FROM accounts WHERE id = ?", 1).Scan(&balance); err != nil {
        _ = txA.Rollback()
        _ = txB.Rollback()
        return err
    }
    // 业务测试在这里断言“未提交写入是否可见”等规则，而不是断言所有数据库相同。
    _ = balance
    _ = txA.Rollback()
    return txB.Commit()
}

这段示例故意不把某一种数据库的结果写死。不同驱动可能把隔离级别映射成不同的数据库语句，也可能在启动事务时直接返回不支持错误；迁移测试应以目标数据库和驱动的正式文档为准。

为什么驱动和数据库边界会改变结果

database/sql 提供统一的事务 API，但它不能替所有数据库定义一套完全相同的锁和可见性规则。sql.IsolationLevel 是跨驱动的表达方式，具体支持情况仍由驱动实现的 ConnBeginTx 和后端数据库决定。

迁移前后的回归清单

1. 列出哪些业务确实依赖并发读写的可见性，不要为所有事务统一套一个级别。
2. 将 Begin() 替换为 BeginTx，把隔离级别作为显式配置传入。
3. 对每个目标驱动确认该级别的支持方式，以及不支持时是返回错误还是由后端解释。
4. 至少编写一个两个事务的并发测试，覆盖未提交写入、提交后读取和冲突处理等业务关心的边界。
5. 每个事务创建后都安排回滚兜底，并在成功路径显式提交，避免连接池复用脏状态。

对我来说，判断 Isolation 是否“生效”的标准已经从“下一条 SQL 有没有不同结果”换成了“并发场景是否符合业务约束”。这样迁移后的代码更容易解释，也更容易在换驱动或换数据库环境时发现真正的兼容问题。

相关问题

sql.TxOptions 的 Isolation 适合直接写成全局默认值吗？

不建议无条件全局化。不同业务对并发可见性、锁等待和吞吐量的取舍不同，应该让事务边界或数据访问层明确表达需要的级别。

只启动一个事务能验证隔离级别吗？

通常不能。单事务只能验证事务本身能否创建、查询和提交，不能充分观察与另一个事务之间的可见性或冲突行为。

驱动不支持目标隔离级别时可以静默降级吗？

只有在业务明确允许且有记录时才考虑降级。更稳妥的做法是保留启动错误，让调用方根据目标数据库的支持情况选择替代级别或直接失败。