Go database/sql DB.Conn 怎样为一次操作绑定独立连接

Go 的 database/sql 里，*sql.DB 代表可被多个 goroutine 共享的连接池，而不是某一条固定连接。大多数查询直接调用 db.QueryContext 或 db.ExecContext 就够了；只有当一组操作必须落在同一个数据库会话、需要读取连接级状态，或需要把后续动作绑定到同一条连接时，才适合调用 db.Conn(ctx)。

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

最小规则是：用带超时的上下文获取 Conn，在它上面完成工作，函数退出前调用 Conn.Close。这个 Close 的含义是把连接归还给池，而不是关闭整个 sql.DB。

先分清 DB、Conn 和 Tx

sql.DB 会从连接池中选择合适的连接执行一次操作。连续两次直接调用 db.ExecContext，不应依赖它们恰好使用同一条底层连接。sql.Conn 则代表一条独立连接；在同一个 Conn 上执行的查询会使用同一个数据库会话。

如果需求只是“这几条 SQL 要么全部成功，要么全部回滚”，优先使用 db.BeginTx，因为事务本身已经绑定到单条连接。如果不需要事务，但确实需要跨多次操作保持会话状态，才使用 DB.Conn。

用上下文获取一条可用连接

DB.Conn(ctx) 在没有可用连接时可能等待，直到有连接归还或上下文被取消。因此不要用一个没有截止时间的上下文承载请求级操作。下面的函数把获取连接、使用连接和归还连接放在同一个生命周期里：

package main

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

func loadBalance(ctx context.Context, db *sql.DB, userID int64) (int64, error) {
    // 限制等待连接和执行查询的总时间，避免池容量紧张时无限排队。
    ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
    defer cancel()

    // Conn 可能等待池中出现可用连接；失败时直接保留上下文错误。
    conn, err := db.Conn(ctx)
    if err != nil {
        return 0, fmt.Errorf("get database connection: %w", err)
    }
    // Close 会把这条连接归还给连接池，不是关闭整个 db。
    defer conn.Close()

    var balance int64
    err = conn.QueryRowContext(ctx,
        "SELECT balance FROM account WHERE user_id = ?", userID,
    ).Scan(&balance)
    if err != nil {
        return 0, fmt.Errorf("load balance: %w", err)
    }
    return balance, nil
}

这里最重要的不是把 db.Conn 包起来，而是让 defer conn.Close() 紧跟在成功获取连接之后。这样即使后面的 SQL 返回错误，也不会漏掉归还动作。若上下文在等待阶段取消，函数直接返回；若已获取连接后取消，驱动支持上下文取消时，正在执行的操作也会收到取消信号。

在同一 Conn 上完成需要会话连续性的操作

连接级临时表、会话变量或某些驱动提供的连接状态，都要求后续 SQL 继续使用同一个数据库会话。可以把这些操作都改成调用 conn.QueryContext、conn.ExecContext，不要中途退回 db.QueryContext：

func prepareSession(ctx context.Context, db *sql.DB) error {
    // 只在这一组操作需要同一会话时才占用独立 Conn。
    conn, err := db.Conn(ctx)
    if err != nil {
        return fmt.Errorf("reserve session: %w", err)
    }
    defer conn.Close()

    // 会话级设置和后续查询必须使用同一个 Conn。
    if _, err := conn.ExecContext(ctx, "SET app_mode = ?", "report"); err != nil {
        return fmt.Errorf("set session mode: %w", err)
    }

    var value string
    if err := conn.QueryRowContext(ctx, "SELECT current_mode()").Scan(&value); err != nil {
        return fmt.Errorf("read session mode: %w", err)
    }
    if value != "report" {
        return fmt.Errorf("unexpected session mode %q", value)
    }
    return nil
}

示例中的 SQL 函数和设置语句由具体数据库与驱动决定，重点是调用关系：同一组操作始终使用 conn。如果只需要原子性，不要为了“固定连接”而手动管理 Conn，直接使用 BeginTx 更清楚。

Rows、事务和 Conn 要按层次释放

拿到 Conn 后，连接的归还不能替代结果集和事务的清理。查询返回 Rows 时，先保证 rows.Close；开启事务后，无论中间哪一步失败，都要回滚或提交。下面的结构把三个资源的边界分开：

func updateWithConn(ctx context.Context, db *sql.DB, id int64) (err error) {
    // 独立 Conn 只服务这次会话型操作，函数返回时一定归还池。
    conn, err := db.Conn(ctx)
    if err != nil {
        return fmt.Errorf("get conn: %w", err)
    }
    defer func() {
        if closeErr := conn.Close(); err == nil && closeErr != nil {
            // 只有主流程没有错误时，才把归还连接的错误作为返回错误。
            err = fmt.Errorf("return conn: %w", closeErr)
        }
    }()

    tx, err := conn.BeginTx(ctx, nil)
    if err != nil {
        return fmt.Errorf("begin tx: %w", err)
    }
    committed := false
    defer func() {
        if !committed {
            // Commit 失败或中途返回时，回滚是安全的收尾动作。
            _ = tx.Rollback()
        }
    }()

    rows, err := tx.QueryContext(ctx, "SELECT status FROM job WHERE id = ?", id)
    if err != nil {
        return fmt.Errorf("query job: %w", err)
    }
    defer rows.Close()

    if !rows.Next() {
        if err := rows.Err(); err != nil {
            return fmt.Errorf("read job: %w", err)
        }
        return fmt.Errorf("job %d not found", id)
    }

    if _, err = tx.ExecContext(ctx, "UPDATE job SET touched = 1 WHERE id = ?", id); err != nil {
        return fmt.Errorf("touch job: %w", err)
    }
    if err = tx.Commit(); err != nil {
        return fmt.Errorf("commit tx: %w", err)
    }
    committed = true
    return nil
}

实际项目可以根据驱动特性调整关闭顺序，但边界要明确：Rows.Close 负责结果集，Tx.Commit/Rollback 负责事务，Conn.Close 负责把独立连接交回 DB。不要把 db.Close() 放进一次请求函数，它会影响所有共享该句柄的 goroutine。

四个容易误用的边界

• 把 Conn 当成永久连接：sql.Conn 仍然属于连接池管理，短任务完成后必须 Close；长期占用会减少其它请求可用的池容量。
• 忽略 Conn 获取等待：连接池达到上限时，DB.Conn 会等待。请求路径应传入带 deadline 的 context，并对取消错误保留上下文语义。
• 同一 Conn 上并发写状态：如果多个 goroutine 共享同一会话状态，顺序和驱动约束会变复杂。没有明确会话需求时直接使用 DB 更稳妥。
• 用 Conn 代替事务：Conn 能保持会话连续性，但不会自动提供原子提交。需要原子性时仍然要 BeginTx、Commit 或 Rollback。

怎么选择 DB、Conn 和 Tx

可以把选择标准压缩成一句话：需要同一会话就拿 Conn，需要原子性就开 Tx，两者都不需要就把工作交给 DB。

常见问题

DB.Conn 会不会创建一条永远不变的物理连接？

不会。它从池中取得或按需打开一条连接，并在 Close 后归还池。下一次调用可能得到另一条物理连接。

Conn.Close 后还能继续查询吗？

不能。关闭后继续操作属于错误用法，标准库会返回连接已结束相关错误。应先完成 Rows 和 Tx 的工作，再 Close Conn。

已经有 Tx 了还需要手动拿 Conn 吗？

通常不需要。事务本身已经绑定到底层连接，直接使用 Tx 的查询与执行方法即可；只有事务之外还要共享同一会话状态时，才重新评估是否需要 Conn。

为什么 Conn 获取要使用请求上下文？

因为池满时获取连接会等待。带 deadline 或取消信号的 context 能让请求在无法及时获得连接时退出，避免等待无限延长。

小结

DB.Conn 解决的是“这一组操作要使用同一数据库会话”的问题。正确写法是用上下文获取、只在确有会话连续性需求时使用、把后续 SQL 全部落到同一个 Conn，并在成功获取后无条件安排 Conn.Close。普通查询交给 *sql.DB，原子性需求交给 Tx，代码会更容易维护。