Go database/sql Tx 提交后查询结果不一致的排查方法

Go database/sql 的 Tx 提交后查询不一致，先区分事务内读取、Commit 回执和事务外的新读取。事务内查询要使用同一个 Tx；只有 Commit 返回 nil 才按成功提交处理；提交后的查询不能继续用已结束的 Tx。确认这三点之后，再比较查询连接目标、主键、租户条件和是否有其他写入，不能仅凭值不同就认定提交丢失。

官方接口地址：https://pkg.go.dev/database/sql#Tx；事务使用说明：https://go.dev/doc/database/execute-transactions。本文不调整数据库隔离级别，不假设项目一定存在副本或缓存，也没有执行真实数据库实验。

先标记你正在比较哪两次读取

设想把 notes 中某条记录的标题改为新值。在事务内查到新标题，是一个观察点；Commit 成功，是另一个观察点；之后从某个查询入口读到标题，又是第三个观察点。它们分别回答“这个事务中读到什么”“提交有没有报告成功”“这次新查询读到什么”，不能相互替代。

排查时先为这三个位置命名：read-in-tx、commit、read-after-commit。把每个位置的错误独立保留。尤其不要写入成功后就提前返回成功，或者让后续查询错误覆盖已经提交这一事实。

事务内用Tx，提交后用新的DB读取

下面函数展示入口区别，保存为现有模块中的 txread.go 即可阅读。调用方提供已配置的 writer 和已存在的 notes 表；示例假定 id 对应记录存在。Go 1.20 及以上可使用其中的 errors.Join。代码未在本文执行，也没有包含驱动安装、表创建或应用连接凭据。

package txread

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

// Rename 用已存在的 notes 表演示三个观察点。
// SQL 使用问号占位符，适用于支持此约定的驱动；其他驱动需调整。
func Rename(ctx context.Context, writer *sql.DB, id int64, title string) (inside, outside string, committed bool, err error) {
    tx, err := writer.BeginTx(ctx, nil)
    if err != nil { return "", "", false, fmt.Errorf("begin: %w", err) }
    defer func() {
        // 提交前的失败路径尝试回滚；不要覆盖原始错误。
        if !committed {
            rbErr := tx.Rollback()
            if rbErr != nil && !errors.Is(rbErr, sql.ErrTxDone) {
                err = errors.Join(err, fmt.Errorf("rollback: %w", rbErr))
            }
        }
    }()
    if _, err = tx.ExecContext(ctx, "UPDATE notes SET title = ? WHERE id = ?", title, id); err != nil {
        return "", "", false, fmt.Errorf("update: %w", err)
    }
    // 事务内读取必须使用 tx，不能换成 writer.QueryRowContext。
    if err = tx.QueryRowContext(ctx, "SELECT title FROM notes WHERE id = ?", id).Scan(&inside); err != nil {
        return "", "", false, fmt.Errorf("read-in-tx: %w", err)
    }
    if err = tx.Commit(); err != nil {
        // 不向调用方返回未经成功提交确认的事务内值。
        return "", "", false, fmt.Errorf("commit: %w", err)
    }
    committed = true
    // 原 tx 已结束；此处是事务外的新读取，不是原事务的一部分。
    if err = writer.QueryRowContext(ctx, "SELECT title FROM notes WHERE id = ?", id).Scan(&outside); err != nil {
        return inside, "", true, fmt.Errorf("read-after-commit: %w", err)
    }
    return inside, outside, true, nil
}

事务内的 ExecContext 与 QueryRowContext 都依赖 tx。提交后的查询使用 writer，而不是继续调用 tx。writer 这个变量名只是帮助表达用途，不能证明它一定连接主库；实际路由和数据库端点仍需由应用配置确认。

函数的 committed 标志有明确边界：true 表示 Commit 已返回 nil；false 可能是根本没有开始成功，也可能是在操作或提交阶段遇错，不是数据库状态的万能判定。代码返回提交错误后不会自动重做 UPDATE。

先看提交回执，再解释查询差异

Commit 失败时，不把事务内查到的值当成成功结果对外返回。特别是通信中断类错误，不应仅凭客户端报错就推断数据库一定没落地，再无条件重放非幂等写入；应按具体驱动和数据库故障语义处理。

Commit 成功但 read-after-commit 失败，是“写入已确认、后续读取失败”，不是同一个失败。调用方可据 committed 标志保留这一事实，避免让通用重试中间件重新执行写操作。生产接口通常应把写入回执与展示查询拆开，错误分类要和业务语义一致。

一旦事务通过 Commit 或 Rollback 结束，继续用原 Tx 查询会遇到已结束事务错误。把这个错误忽略，再打印未被 Scan 写入的变量，也可能被误认为查询读到了空值。

按连接目标和查询条件缩小范围

在确认提交成功后，首先用相同主键、相同租户条件和明确的数据库端点做新读取。若应用确实有读写分离，比较 writer 与 reader 的配置；若读取还经过缓存，则区分数据库值与缓存展示值。它们是条件性的排查分支，database/sql 本身不会替所有应用保证副本或缓存立即同步。

即使使用相同 DB 句柄，后续查询也不属于先前结束的事务。另一并发操作可能在两次观察之间再次修改同一行。因此，不能把示例里的 inside == outside 写成不带前提的永久断言。需要精确归因时，可由业务模型提供修订号或操作标识，比较同一版本；本文不引入新的隔离策略。

还有一种差异来自查询本身：写入按 id，展示查询却按另一个筛选条件、返回多行中的任意一行，或 Scan 的列次序与变量不一致。排查记录宜保留语句标识、脱敏参数摘要、目标环境和阶段错误，不要记录密码或完整连接串。

用阶段记录选择下一步

读者可在隔离的测试数据库里预置一条记录，调用函数，分别检查错误阶段和 committed，再对照已知并发条件判断 inside 与 outside。这里不提供虚构的 PASS 输出；用 mock 可以检查调用顺序，但不能证明真实数据库可见性或读写路由正确。

提交后必须拿回同一条物理连接吗？

不应把它当成通用修复。事务外读取要遵循应用的数据源约定；若问题是读到另一端点或另一版本，仅讨论连接是否相同会偏离原因。

defer Rollback 会撤销已经成功的 Commit 吗？

已结束事务不会因此重新变为未提交。示例用 committed 跳过成功后的清理；提交前错误路径则保留回滚机会。

只看 Exec 返回 nil 能确认更新了目标行吗？

不能。语句没有报错不代表一定命中了期望记录，需结合查询条件和具体驱动的受影响行语义判断。本文用存在的 id 作为示例前提，不把 Exec 成功当成业务成功。

选择排查入口时遵循一条原则：事务内状态问 Tx，提交结果问 Commit，之后的展示值问那一次新读取。把三类观察分开，才能对差异作出有边界的解释。