4. Go database/sql 包详解：sql.DB 对象、连接池的默认行为与连接泄漏

在 Go 的数据库编程中，database/sql 是官方提供的核心抽象层。它定义了一套统一的接口，让开发者可以用相同的代码操作 MySQL、PostgreSQL、SQLite 等不同数据库。但真正驱动这套接口高效运转的，是隐藏在 sql.DB 对象背后的连接池机制。理解这个机制，是优化 REST API 查询性能、避免连接泄漏的前提。

4.1 sql.DB 对象：不是连接，而是连接池的管理器

很多初学者误以为 sql.Open() 返回的 *sql.DBsql.DB 实际上是一个连接池管理器，它负责维护一组可复用的数据库连接，并处理连接的创建、分配、回收和生命周期管理。

下图展示了 sql.DB 对象在 Gin 应用中的核心位置与连接池的内部结构：

4.2 连接池的默认行为与关键参数

database/sql 的连接池默认行为是“智能”的，但如果不了解其默认值，很容易在生产环境中遇到性能瓶颈。下表列出了连接池的核心参数及其默认行为：

4.3 连接泄漏的常见原因

连接泄漏是 Go 数据库编程中最常见、也最隐蔽的问题之一。泄漏的本质是：从连接池中“借”出的连接，没有被正确“还”回池中。这会导致空闲连接池逐渐枯竭，最终所有新请求都阻塞在等待队列中，引发服务雪崩。

以下是四种最常见的连接泄漏场景：

1. 忘记关闭 rows 对象：执行 db.Query() 返回的 *sql.Rows 对象，在遍历完成后必须调用 rows.Close()。如果提前 break 或 return 而忘记关闭，底层的数据库连接将一直被占用。
2. 忘记关闭 stmt 对象：预编译的 *sql.Stmt 对象在使用后也需要关闭，否则其关联的连接不会被释放。
3. 事务未提交或回滚：开启事务 tx, _ := db.Begin() 后，如果没有调用 tx.Commit() 或 tx.Rollback()，事务持有的连接将永远无法归还。
4. 错误处理路径遗漏：在复杂的错误处理逻辑中，某些分支提前 return 了，但忘记在 return 前关闭 rows 或回滚事务。

下图对比了正常连接生命周期与连接泄漏的生命周期：

4.4 安全编码模式：defer 是防泄漏的第一道防线

Go 的 defer 语句是防止连接泄漏的最有效工具。无论函数是正常结束还是因错误提前返回，defer 都会确保资源被释放。以下是标准的安全编码模式：

// 安全模式 1：查询后立即 defer rows.Close()
func getUser(db *sql.DB, id int) (*User, error) {
    rows, err := db.Query("SELECT id, name FROM users WHERE id = ?", id)
    if err != nil {
        return nil, err
    }
    defer rows.Close()  // 确保 rows 被关闭

    var user User
    if rows.Next() {
        err = rows.Scan(&user.ID, &user.Name)
        if err != nil {
            return nil, err
        }
    }
    return &user, rows.Err()
}

// 安全模式 2：事务必须 defer 回滚
func updateUser(db *sql.DB, id int, name string) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    defer tx.Rollback()  // 如果 Commit 成功，Rollback 是空操作

    _, err = tx.Exec("UPDATE users SET name = ? WHERE id = ?", name, id)
    if err != nil {
        return err
    }

    return tx.Commit()
}