Go database/sql 事务提交后查询为什么看不到数据怎样构造最小复现

先说结论：在同一个主库、同一个 schema 和相同查询条件下，database/sql 的事务成功执行并且 Commit 返回 nil 后，后续通过同一个 *sql.DB 查询通常应该能看到已提交数据。查不到时，优先检查是否忽略了 Exec 或 Commit 的错误、事务上下文是否被取消、读写是否落到了不同数据库，以及查询是否走了尚未同步的只读副本。

官方地址：https://pkg.go.dev/database/sql

先把“提交成功”和“查询可见”放在同一条链路上

Go 的 sql.DB 不是一条永久连接，而是一个可并发使用的连接池。调用 BeginTx 后返回的 Tx 会绑定到一条底层连接；调用 Commit 或 Rollback 后，这条连接才回到连接池。因此，提交后的 db.QueryRowContext 可能复用原连接，也可能取到池中的另一条连接。

这不会自动造成“提交后的数据被 database/sql 缓存住”。如果读写确实指向同一主库，且事务提交成功，问题通常在业务错误处理、连接配置、schema、查询条件或数据库拓扑，而不是 DB 对结果做了缓存。

用最小复现固定写入、提交和读回

复现时先排除读副本和复杂业务层，只保留一份 *sql.DB、一个事务和一次读回。下面代码使用 SQLite 驱动名作为示意，真实项目请替换为自己的驱动和 DSN；重点是错误必须原样保留下来。

package main

import (
	"context"
	"database/sql"
	"fmt"
	"log"
	"time"

	_ "github.com/mattn/go-sqlite3"
)

func writeAndRead(ctx context.Context, db *sql.DB) error {
	// 给事务设置独立超时，避免请求取消后把回滚误判成“提交后读不到”。
	txCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
	defer cancel()

	tx, err := db.BeginTx(txCtx, nil)
	if err != nil {
		return fmt.Errorf("开始事务失败: %w", err)
	}
	// 提交成功时 Rollback 会返回 ErrTxDone，作为兜底清理即可。
	defer tx.Rollback()

	_, err = tx.ExecContext(txCtx,
		"INSERT INTO users(name) VALUES (?)", "alice")
	if err != nil {
		// 写入失败必须带出原始错误，不能继续 Commit 再假设有数据。
		return fmt.Errorf("事务写入失败: %w", err)
	}

	if err = tx.Commit(); err != nil {
		// Commit 也可能失败；此时不能把本次写入当成已持久化。
		return fmt.Errorf("事务提交失败: %w", err)
	}

	var name string
	err = db.QueryRowContext(ctx,
		"SELECT name FROM users WHERE name = ?", "alice").Scan(&name)
	if err != nil {
		return fmt.Errorf("提交后读回失败: %w", err)
	}
	log.Println("读回成功:", name)
	return nil
}

这个复现的判断标准很明确：若 Commit 返回错误，不能进入读回结论；若 Commit 成功而读回返回 sql.ErrNoRows，就把注意力转到 DSN、schema、查询条件和数据库路由。不要先增加重试次数，因为重试只会掩盖错误发生在哪一层。

六类原因对应六种排查动作

把查询路由和事务边界分开处理

在单库环境中，推荐把“事务写入”和“提交后读回”做成两个清晰的阶段：事务内只负责原子写入，提交结果由调用方判断；提交之后的查询明确指定读主库还是读副本。不要让一个名为 db 的全局变量在中间偷偷切换 DSN，也不要在事务仍未结束时用另一个连接猜测结果。

// 只在 Commit 成功后进入读回阶段，并明确选择一致性读连接。
func createThenLoad(ctx context.Context, writeDB, primaryReadDB *sql.DB) (string, error) {
	tx, err := writeDB.BeginTx(ctx, nil)
	if err != nil {
		return "", fmt.Errorf("begin: %w", err)
	}
	defer tx.Rollback()

	// 使用同一事务完成写入，避免一半写入落在事务外。
	if _, err = tx.ExecContext(ctx,
		"INSERT INTO orders(order_no, status) VALUES (?, ?)", "O-1001", "created"); err != nil {
		return "", fmt.Errorf("insert order: %w", err)
	}
	if err = tx.Commit(); err != nil {
		return "", fmt.Errorf("commit order: %w", err)
	}

	var status string
	// 读后写必须读主库；若业务允许最终一致，再把副本延迟作为显式状态处理。
	if err = primaryReadDB.QueryRowContext(ctx,
		"SELECT status FROM orders WHERE order_no = ?", "O-1001").Scan(&status); err != nil {
		return "", fmt.Errorf("load committed order: %w", err)
	}
	return status, nil
}

如果项目没有独立的主库句柄，至少要在数据访问层传递读一致性意图，例如 ReadPrimary 或 AllowReplicaLag。这比在每个调用点盲目 Sleep 更容易审查，也不会把复制延迟误当成 Go 事务语义。

上线前的最小检查清单

• 事务是否总是以 Commit 或 Rollback 结束？
• 是否同时检查了 BeginTx、ExecContext、Commit 和读回的错误？
• 写入和读回是否使用同一个环境、租户、数据库和 schema？
• 读后写接口是否明确要求主库读取，而不是默认读副本？
• 日志是否能关联请求、事务结果、最终查询条件和读路由？

完成这些检查后，最小复现应当能把问题收敛到“事务没有成功提交”或“提交成功但读路径不是同一个可见性范围”。前者修错误处理，后者修连接配置和一致性策略，不要把两类问题混成一个重试参数。

常见问题

Commit 返回 nil 后，database/sql 会保证下一次查询一定走同一条连接吗？

不会。*sql.DB 管理的是连接池；但在同一主库和一致 schema 下，提交后的数据应按数据库语义可见，不需要依赖同一条物理连接。

为什么 defer tx.Rollback 不会把已经提交的数据撤销？

提交或回滚后事务已经结束，后续 Rollback 会被忽略或返回事务已结束的状态。它的作用是覆盖提前返回的错误分支，避免遗留未结束事务。

读副本延迟应该在 Go 里循环查询吗？

不要默认循环。先明确读后写是否必须强一致；必须强一致就读主库或使用数据库提供的一致性机制，允许最终一致才把延迟和超时设计成业务策略。