sql.DB是连接池管理器而非连接，真实连接惰性建立，需显式Ping验证；应全局复用，合理设置MaxOpenConns（建议数据库上限×0.8）、MaxIdleConns（为MaxOpenConns的1/2~2/3）和ConnMaxLifetime（略小于DB超时）；事务必须显式Commit或Rollback，否则连接泄漏。
为什么 sql.DB 本身不是连接，而是连接池管理器
很多人误以为调用 sql.Open() 就建立了真实数据库连接，其实它只初始化了一个连接池管理器，不校验数据库是否可达。真实连接是在第一次执行 Query()、Exec() 等操作时惰性建立的。如果网络不通或认证失败，错误会延迟抛出，导致排查困难。
- 务必在初始化后显式调用
db.Ping()做连通性验证，否则服务启动成功但首次请求才报错 -
sql.DB是并发安全的，可全局复用，**不要为每次请求新建sql.DB实例** - 连接池行为由
SetMaxOpenConns()、SetMaxIdleConns()、SetConnMaxLifetime()共同控制，缺一不可
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才合理
这两个值不是越大越好。设太高会导致数据库端连接数超限（如 MySQL 默认 max_connections=151），设太低又容易因排队引发延迟毛刺。
-
SetMaxOpenConns(n)：建议设为数据库允许的最大连接数 × 0.8，再结合 QPS 估算。例如 DB 上限 200，应用峰值 QPS 100，平均查询耗时 50ms → 理论并发约 5，设 10–20 更稳妥 -
SetMaxIdleConns(n)：通常设为MaxOpenConns的 1/2 到 2/3。过小会导致频繁建连/销毁；过大则空闲连接占用资源 - 若使用连接池监控（如 Prometheus +
database/sql指标），重点关注sql_open_connections和sql_idle_connections曲线是否稳定
为什么必须调用 SetConnMaxLifetime 防止 stale connection
数据库连接可能被中间件（如 ProxySQL、AWS RDS Proxy）或数据库自身（如 MySQL 的 wait_timeout）主动断开。Go 连接池不会自动感知这种“被动断连”，下次复用该连接时会返回 "invalid connection" 或 "i/o timeout" 错误。
- 设置
db.SetConnMaxLifetime(60 * time.Second)强制连接在 60 秒后被回收，避免复用陈旧连接 - 该值应略小于数据库侧的连接超时（如 MySQL
wait_timeout=300，则设 240s） - 注意：它只影响已空闲的连接；正在使用的连接不受影响，超时后会在归还时被关闭
事务中忘记 tx.Commit() 或 tx.Rollback() 会怎样
事务对象 *sql.Tx 不是连接池的一部分，但它底层持有从池中取出的连接。如果未显式提交或回滚，该连接会一直被占用，直到 GC 触发 tx.finalize()（依赖 runtime.SetFinalizer），但这个时机不可控。
立即学习“go语言免费学习笔记（深入）”；
- 连接长期被占会导致
sql_open_connections持续升高，最终池满，新请求阻塞在acquireConn - 最佳实践：用
defer tx.Rollback()开头，再在成功路径上显式tx.Commit()覆盖 - 更安全的方式是封装事务函数，利用闭包确保终态处理：
func withTx(db *sql.DB, fn func(*sql.Tx) error) error {
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if p := recover(); p != nil {
tx.Rollback()
panic(p)
}
}()
if err := fn(tx); err != nil {
tx.Rollback()
return err
}
return tx.Commit()
}连接池调优没有银弹，关键在于理解每个参数的物理意义，并结合数据库实际负载与监控反馈持续调整。最容易被忽略的是 SetConnMaxLifetime 和事务终态处理——它们不会立刻报错，但会在高并发或长周期运行后突然爆发问题。
