sql.Open不立即建连，连接池参数须在首次操作前设置；SetMaxOpenConns必须设为合理值（≤数据库max_connections×0.8），SetMaxIdleConns≤前者且建议设为1/4～1/2；SetConnMaxLifetime防连接老化，SetConnMaxIdleTime（Go 1.15+）主动清理空闲连接。
sql.Open 不会立即建连，但连接池参数必须尽早设置
很多人以为 sql.Open 会立刻连上数据库，其实它只校验 DSN 格式并初始化连接池结构。真正建连发生在第一次 db.Query 或 db.Exec 时。这意味着：如果在 sql.Open 后没及时调用 SetMaxOpenConns 等方法，连接池就可能以默认值（比如 MaxOpenConns=0，即无上限）开始服务，导致突发流量直接打爆 MySQL 的 max_connections。
实操建议：
- 所有
SetXXX方法必须在首次数据库操作前调用，最好紧接在sql.Open之后、db.Ping()之前 - 不要依赖“后面再配”，因为连接池一旦开始分发连接，参数变更只影响后续新连接，已有连接不受影响
-
db.SetMaxOpenConns(0)是危险操作，生产环境必须显式设为合理值
SetMaxOpenConns 和 SetMaxIdleConns 的数值关系容易搞反
这两个参数不是独立调节的，它们有隐含约束：SetMaxIdleConns 不能大于 SetMaxOpenConns。如果设成 db.SetMaxOpenConns(20) 再调 db.SetMaxIdleConns(30)，后者会被静默截断为 20，且不会报错——你看到的 db.Stats().Idle 永远 ≤ OpenConnections。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 监控显示
IdleConnections始终为 0，即使并发很低 - 频繁出现连接建立延迟，明明空闲连接应该够用
- 日志里反复出现
driver: bad connection，其实是连接被强制关闭后重连
推荐做法：
-
SetMaxIdleConns设为SetMaxOpenConns的 1/4 到 1/2（例如 25→6～12），保证热连接复用率 - 避免设得过小（如 1 或 2），否则高并发下每次请求都可能新建连接
- 注意：MySQL 服务端
max_connections（默认 151）是硬上限，应用层总连接数要留出余量给其他服务或 DBA 工具
ConnMaxLifetime 和 ConnMaxIdleTime 的单位与生效时机不同
SetConnMaxLifetime 控制单个连接从创建起最多活多久；SetConnMaxIdleTime 控制连接空闲多久后被清理。两者单位都是 time.Duration，但行为差异很大：
-
SetConnMaxLifetime是“出生后计时”，到期连接会在下次归还池时被关闭，不主动中断当前使用中连接 -
SetConnMaxIdleTime是“躺平时计时”，空闲连接超时后会被后台 goroutine 主动关闭，不影响正在使用的连接 - MySQL 默认
wait_timeout=28800（8 小时），所以SetConnMaxLifetime应设为略小于该值（如 7h），否则连接可能被服务端先断开
容易踩的坑：
- 把
SetConnMaxLifetime设得太短（如 30s），导致连接刚复用几次就被销毁，徒增握手开销 - 忽略
SetConnMaxIdleTime，让大量空闲连接长期滞留，占用 MySQL 句柄却不干活 - 两个值设成一样，造成连接在空闲状态下被误判为“寿命到”，实际是空闲超时触发的清理
连接泄漏往往不是代码漏 Close，而是事务没提交或回滚
Go 的 database/sql 连接池本身不暴露 Close 方法，连接用完自动归还。所谓“泄漏”，90% 是指连接被借出后卡在未完成的事务里——比如 tx, _ := db.Begin() 之后忘了 tx.Commit() 或 tx.Rollback()，这个连接就一直被事务占用，无法归还池中。
验证方式：
- 查
db.Stats().OpenConnections持续上涨，但IdleConnections几乎为 0 - MySQL 端执行
show processlist，看到大量Command=Sleep且State=Waiting for table metadata lock或类似状态 - 用
defer tx.Rollback()包裹事务逻辑，再加if err == nil { tx.Commit() }是最稳妥写法
复杂点在于：有些 ORM 或封装层会隐藏 Begin 调用，或者在 panic 后没正确 recover 并 rollback。这类问题不会立刻暴露，但压测或上线后几天内连接数会缓慢爬升，直到触发 too many connections 错误。
