SetMaxOpenConns设得过大易压垮数据库，因超出DB默认连接上限（如MySQL 151、PG 100）会拒连，且大量空闲连接占用槽位并可能被DB超时kill，导致driver: bad connection；建议设为业务峰值并发的1.5–2倍且不超DB max_connections的70%。
SetMaxOpenConns 为什么设得太大会出问题
连接数不是越多越好，SetMaxOpenConns 设得过大，会直接压垮数据库。MySQL 默认最大连接数常为 151，PostgreSQL 通常为 100，超出就会拒绝新连接，报错 ERROR: sorry, too many clients already 或 sql: database is closed（实际是被服务端断开）。更隐蔽的问题是：大量空闲连接长期占用 DB 连接槽位，却没在干活，还可能触发 DB 的 idle timeout 主动 kill，导致 Go 侧出现 driver: bad connection。
实操建议：
- 先观察业务高峰期的平均并发 SQL 执行量（比如用 pprof + 慢日志估算），
SetMaxOpenConns建议设为该值的 1.5–2 倍，上限不超过 DB 侧max_connections的 70% - 对读多写少的服务，可适当调低（如 20–50）；高吞吐写入服务可设到 80–120，但必须同步确认 DB 配置余量
- 线上务必开启
SetMaxIdleConns（见下一条），否则MaxOpen全是活跃连接，毫无缓冲余地
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对使用
SetMaxIdleConns 控制池中最多保留几个空闲连接，SetConnMaxLifetime 控制单个连接最长存活时间。不配对就容易出两类典型故障：一是连接泄漏（idle 连接一直不释放，DB 端堆积大量 sleep 连接）；二是 stale connection（连接在 DB 侧被超时回收后，Go 池里还拿着，下次复用直接报 invalid connection）。
实操建议：
-
SetMaxIdleConns一般设为SetMaxOpenConns的 1/2 到 2/3（例如 Open=100 → Idle=60），避免频繁建连又立刻丢弃 -
SetConnMaxLifetime推荐设为 DB 侧wait_timeout（MySQL）或tcp_keepalives_idle（PG）的 70%～90%，常见值为 30m～1h；切忌设为 0（永不回收）或过短（如 30s，徒增建连开销） - 如果 DB 前面有代理（如 ProxySQL、HAProxy），还要额外考虑代理层的连接空闲超时，此时
ConnMaxLifetime应小于代理配置
QueryContext vs ExecContext 要带 context，且 timeout 不能只靠连接池
连接池本身不处理超时，SetConnMaxLifetime 是连接生命周期，不是 SQL 执行超时。真正防慢查询拖垮池子，得靠 context.WithTimeout 传给 QueryContext 或 ExecContext。否则一个卡住的 SELECT 可能占着连接几十秒，池子里其他 goroutine 全在 acquireConn 上阻塞等待。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 所有 DB 调用必须走
Context版本函数，不要用无 context 的Query/Exec - HTTP handler 中常用
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)，然后 defer cancel()；后台任务可放宽到 10–30s，但必须设 - 注意：context timeout 触发后，连接不一定立即归还池子——它会等当前操作结束（或 driver 主动中断），所以也要配合 DB 层的
innodb_lock_wait_timeout（MySQL）或lock_timeout（PG）做兜底
如何验证连接池是否真的调好了
光改参数不看效果等于没调。关键指标不是“有没有报错”，而是“连接复用率”和“等待获取连接的延迟”。Go 的 database/sql 提供了 DB.Stats()，但要注意它返回的是**累计值**，需周期采集差值才能看出趋势。
实操建议：
- 每 10 秒打一次
db.Stats()，重点关注WaitCount（等待连接的总次数）和WaitDuration（总等待时长）；如果WaitCount > 0且WaitDuration持续增长，说明MaxOpenConns不够或存在慢查询堵住连接 - 用
Idle和Open的比值判断复用效率：理想情况下Idle / Open > 0.4；如果长期Idle == 0，大概率是MaxIdleConns太小或ConnMaxLifetime过短 - DB 侧也要查：MySQL 用
SHOW PROCESSLIST看 sleep 连接数；PostgreSQL 查pg_stat_activity中state = 'idle'的数量，与 Go 池中Idle对不上，就说明有连接未正确归还（比如 defer db.Close() 写错位置、panic 未 recover）
连接池参数之间有强耦合，单独调某一个往往无效；最易忽略的是 DB 侧配置和网络中间件的 timeout 与 Go 客户端不一致，这会导致连接状态错乱，现象就是偶发的 driver: bad connection，但日志里找不到明确原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
