Go 事务提交成功但后续读取不到数据怎么办

Go 里出现“事务提交成功，但紧接着查询不到刚写入的数据”，先不要把原因归结为数据库没有提交。优先确认四件事：Commit 的错误是否真的为 nil，前后查询条件是否一致，查询是否误用了事务外的 sql.DB，以及提交后的读取是否被路由到了有延迟的副本。

官方资料：https://go.dev/doc/database/execute-transactions

正确的判断顺序是：先保留并处理 Commit 返回值，再确认写入行数和查询参数；事务内继续用 Tx，提交后按明确的主库或副本策略读取。只要把 Tx 和 DB 混在一起，看到的就可能不是同一个事务视图。

• Commit 返回非 nil 时，不能把事务内查询结果当成最终结果。
• 同一个 sql.Tx 内的后续读取，应该调用 Tx.QueryContext 或 Tx.QueryRowContext。
• 提交后的新查询可能使用连接池中的另一条连接；如果系统有读副本，还要确认读取路由。

先确认提交真的成功了

Go 官方事务流程是开始事务、执行操作、成功后提交，出错则回滚。这里最容易漏掉的是把 Commit 当成没有错误的收尾动作，甚至直接忽略返回值。实际上，只有 Commit 返回 nil，事务内的更新才可以按成功处理。

func createOrder(ctx context.Context, db *sql.DB, userID int64) error {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    // 失败路径统一回滚；提交成功后，Rollback 通常只会返回已完成状态。
    defer tx.Rollback()

    result, err := tx.ExecContext(ctx,
        "INSERT INTO orders(user_id, status) VALUES(?, ?)",
        userID, "created",
    )
    if err != nil {
        return err
    }
    // RowsAffected 用来确认驱动报告的写入行数，不能替代 Commit 的判断。
    affected, err := result.RowsAffected()
    if err != nil {
        return err
    }
    if affected != 1 {
        return fmt.Errorf("unexpected affected rows: %d", affected)
    }
    // Commit 的错误必须向调用方返回，否则后续读取可能建立在假成功上。
    return tx.Commit()
}

如果调用方只看到“插入函数没有报错”，还要检查这个函数是否真的返回了 tx.Commit() 的错误。数据库驱动可能在提交阶段才报告约束、连接或上下文相关问题。

事务内读取和提交后读取不是一回事

事务开始后，Tx 代表这次事务使用的数据库连接和事务语义。写入后如果还没有提交，应该用同一个 Tx 读取；提交成功后，事务已经结束，后续读取通常通过 sql.DB 从连接池获取连接。

下面的函数把“事务内确认”和“提交后查询”拆成两个清楚的阶段。这样做的价值不是让结果必然出现，而是让每一个阶段的视图和错误都可解释。

func saveAndRead(ctx context.Context, db *sql.DB, userID int64) (string, error) {
    tx, err := db.BeginTx(ctx, nil)
    if err != nil {
        return "", err
    }
    defer tx.Rollback()

    if _, err = tx.ExecContext(ctx,
        "INSERT INTO user_notes(user_id, note) VALUES(?, ?)",
        userID, "ready",
    ); err != nil {
        return "", err
    }

    var inside string
    // 未提交前使用 Tx 读取，保证读写处在同一事务边界。
    if err = tx.QueryRowContext(ctx,
        "SELECT note FROM user_notes WHERE user_id = ? ORDER BY id DESC LIMIT 1",
        userID,
    ).Scan(&inside); err != nil {
        return "", err
    }
    // 提交错误不能忽略；nil 才表示这次事务可以交给后续流程。
    if err = tx.Commit(); err != nil {
        return "", err
    }

    var after string
    // 提交后的查询是新阶段，读取路由由 db 的配置和驱动决定。
    if err = db.QueryRowContext(ctx,
        "SELECT note FROM user_notes WHERE user_id = ? ORDER BY id DESC LIMIT 1",
        userID,
    ).Scan(&after); err != nil {
        return "", err
    }
    return after, nil
}

如果 inside 能读到而 after 读不到，代码层面最值得检查的是提交后的连接路径，而不是重复调用 Commit。如果连 inside 都读不到，则应回到插入错误、查询条件、事务隔离和表约束继续定位。

最常见的误区是把 Tx 和 DB 混用

官方文档特别提醒：事务期间不要直接调用非事务的 sql.DB 方法。DB 管理的是连接池，db.QueryContext 可能拿到另一条连接；它既不自动加入当前 Tx，也不等同于“在当前事务上查询”。

func wrongRead(ctx context.Context, db *sql.DB, tx *sql.Tx, id int64) error {
    // 错误示例：这次查询没有沿用 tx，可能观察到不同的事务视图。
    var status string
    return db.QueryRowContext(ctx,
        "SELECT status FROM orders WHERE id = ?", id,
    ).Scan(&status)
}

func rightRead(ctx context.Context, tx *sql.Tx, id int64) (string, error) {
    // 正确边界：事务尚未提交时，用 Tx 的查询方法读取。
    var status string
    err := tx.QueryRowContext(ctx,
        "SELECT status FROM orders WHERE id = ?", id,
    ).Scan(&status)
    return status, err
}

还有一种隐蔽情况是把事务相关的 BEGIN、COMMIT 字符串直接交给普通连接执行。Go 官方建议使用 DB.Begin 或 DB.BeginTx 管理事务，让驱动和连接生命周期保持一致。

用四个证据判断到底是哪一层看不到

不要只记录“查不到”这一句日志。排查时至少把事务阶段、业务主键、写入行数、Commit 错误和读取目标记录下来；参数值可以脱敏，但不能完全省略，否则无法判断前后查询是否真的问了同一条数据。

尤其要注意租户条件、软删除字段和状态过滤：插入成功不代表一定满足下一条查询的全部条件。把最终 SQL 的结构、关键参数和读取数据源一起记录，通常比提高重试次数更快找到原因。

提交后仍读不到时检查副本和隔离边界

如果 Commit 已返回 nil，并且同样的主键在主库能读到，但应用的默认读取入口读不到，问题可能在读写分离或副本复制延迟。这个结论依赖你的数据库和代理配置，不能用 Go 标准库单独推断出一个固定等待时间。

工程上可以按需求选择：

• 创建订单后必须立刻展示：提交后的第一次读取走主库，或直接返回事务中已经确定的对象。
• 允许短暂延迟的列表页：可以继续读副本，但界面和接口要接受短暂空结果。
• 跨请求要求读己之写：在请求上下文中携带路由标记、版本号或提交位点，由读路由层决定数据源。

隔离级别也会影响事务中的快照观察，但它不能修复错误的连接路由或错误的查询条件。先明确“是在提交前读不到，还是提交后从副本读不到”，再讨论隔离级别，排查顺序会更短。

结论与相关问题

Go 事务提交后读取不到数据，最稳妥的处理顺序是：检查写入和 Commit 错误，核对前后查询条件，事务内坚持使用 Tx，提交后确认主库或副本路径，最后再分析隔离级别和并发场景。把“提交成功”和“某个读取入口立刻可见”分开记录，问题就不会被混成一句模糊的数据库异常。

Commit 返回 nil 后，还需要 Rollback 吗？

可以保留函数开头的 defer tx.Rollback() 作为失败兜底。提交成功后事务已完成，这次回滚通常只是返回已完成状态，不应再把它当成一次新的业务操作。

事务内能不能用 db.QueryRowContext？

不建议。它不属于当前 Tx，可能拿到连接池中的另一条连接。事务内读取使用 tx.QueryRowContext，提交后再按明确的数据源策略使用 db.QueryRowContext。

重试查询能解决提交后读不到吗？

只有在你已经确认是可接受的副本延迟，并且重试不会制造重复副作用时才考虑。若根因是查询条件、提交错误或读错租户，重试只会延迟暴露问题。