Go 的 sql.DB 自带线程安全连接池，无需手动实现；需合理配置 MaxOpenConns、MaxIdleConns、ConnMaxLifetime 和 ConnMaxIdleTime；应全局复用单个 sql.DB 实例，事务中必须使用 sql.Tx 对象操作。

Go sql.DB 本身已内置连接池，不需要手动实现

很多人一想到“并发访问数据库”，第一反应是自己写锁、建连接池、做限流。其实 sql.DB 在 Go 标准库中早已不是“单个连接”的封装，而是一个**带自动连接池的数据库句柄**。它默认支持并发调用 Query、Exec、Prepare 等方法，无需额外同步控制。

关键点在于：你拿到的 *sql.DB 是线程安全的，可被任意 goroutine 共享使用。它的连接池会在后台自动复用、新建、回收和关闭空闲连接。

必须显式配置 MaxOpenConns 和 MaxIdleConns

不设限会导致连接数爆炸——尤其在高并发或短连接场景下，数据库可能被撑爆。默认值（0）表示“无上限”，这在生产环境极其危险。

• db.SetMaxOpenConns(n)：控制最多同时打开多少个底层数据库连接（含正在执行的 + 空闲的）
• db.SetMaxIdleConns(n)：控制连接池中最多保留多少个空闲连接（不活跃但未关闭）
• db.SetConnMaxLifetime(d)：强制连接在存活时间超过 d 后被关闭并重建（防长连接僵死）
• db.SetConnMaxIdleTime(d)：空闲连接最长保留时间（Go 1.15+ 才有，避免连接池积压陈旧连接）

典型配置示例：

立即学习“go语言免费学习笔记（深入）”；

db, _ := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)
db.SetConnMaxLifetime(5 * time.Minute)
db.SetConnMaxIdleTime(5 * time.Minute)

不要在每次请求中调用 sql.Open

常见错误是把 sql.Open 放在 HTTP handler 或业务函数里，导致每来一次请求就新建一个 *sql.DB 实例。这不仅浪费资源，还会绕过连接池复用逻辑，迅速耗尽数据库连接数。

• sql.Open 不真正建连接，只做验证和初始化；真正的连接是在第一次 db.Query 等操作时惰性建立的
• 应全局复用一个 *sql.DB 实例（比如放在包变量或依赖注入容器中）
• 如果需要多套配置（如读写分离），才考虑多个 *sql.DB，但仍需各自独立配置连接池参数

事务内务必用 Tx 对象，别混用 db 和 tx

在事务中继续用 db.Query 而非 tx.Query，会导致查询脱离事务上下文，出现数据不一致或锁等待异常。

• 事务开始后，所有操作必须通过 *sql.Tx 对象进行，包括 Query、Exec、Prepare
• tx.Commit() 或 tx.Rollback() 后，该 tx 对象不可再使用，也不可重复调用
• 事务超时或 panic 时，记得用 defer tx.Rollback() 配合 if err == nil 判断来避免误回滚

正确用法片段：

tx, err := db.Begin()
if err != nil {
    return err
}
defer func() {
    if p := recover(); p != nil || err != nil {
        tx.Rollback()
    }
}()
_, err = tx.Exec("INSERT INTO users(name) VALUES(?)", "alice")
if err != nil {
    return err
}
return tx.Commit()

连接池参数不是“设了就完事”，它必须和你的数据库服务端最大连接数、业务 QPS、平均响应时间共同推算。一个没调优的 MaxOpenConns 比没有连接池更危险——它会让问题延迟暴露，直到某次流量高峰突然全链路超时。