SetMaxOpenConns应设为数据库max_connections的60%～80%，并配合SetMaxIdleConns（1/2～1/3）、SetConnMaxLifetime（略小于DB超时）及SetConnMaxIdleTime（5分钟）调优，以避免连接耗尽或失效。
db.SetMaxOpenConns 设多少才不翻车
设太高会压垮数据库（比如 MySQL 默认 max_connections=151，你设成 200 就直接拒绝新连接）；设太低会导致请求排队，db.Stats().WaitCount 持续上涨，延迟毛刺明显。
实操建议：
- 先查数据库上限：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或SELECT setting FROM pg_settings WHERE name = 'max_connections';（PostgreSQL） -
SetMaxOpenConns推荐设为数据库上限的 60%～80%，留余量给后台任务、其他服务或突发流量 - 别只看 QPS 和平均耗时硬算理论值——100 QPS × 20ms = 2 个并发连接？那是理想模型，线上必须加安全系数，起步至少 10～20
- 观察
db.Stats().OpenConnections：长期接近SetMaxOpenConns值，说明不够用；长期低于 30%，大概率设高了，浪费资源
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对调
只调 SetMaxOpenConns 不碰 idle 和 lifetime，是线上最常见的“半截优化”——连接池看着在跑，实际满屏 read: connection reset by peer 或 ERROR 2013 (HY000): Lost connection。
原因很简单：空闲连接没人管，数据库早把它们静默断了，Go 还傻乎乎往里塞请求。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
-
SetMaxIdleConns一般设为SetMaxOpenConns的 1/2 到 1/3（比如最大开 50，空闲保持 15～25），太高堆着占 DB 资源，太低频繁建连 -
SetConnMaxLifetime推荐 15～30 分钟（如30 * time.Minute），且必须略小于数据库侧的超时设置（例如 MySQLwait_timeout=300，你就设 240s） - Go 1.15+ 加上
SetConnMaxIdleTime(5 * time.Minute)，让空闲太久的连接主动释放，防 NAT、LB、防火墙悄悄踢掉
db.Stats() 是唯一能信的“体检报告”
很多人只靠 db.Ping() 判断连接池健康，这等于只测了门铃响不响，不管屋里有没有人。真正要盯的是 db.Stats() 返回的实时状态。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
常见错误现象：
-
InUse持续增长、Idle趋近于 0，且不随请求结束回落 → 很可能有未Commit()/Rollback()的*sql.Tx，连接被锁死 -
WaitCount和WaitDuration明显上升 → 连接不够用，或者 SQL 执行太慢拖住连接 -
MaxIdleClosed高频增加 → 空闲连接被频繁回收，说明SetMaxIdleConns设得不合理，或连接利用率极低
一个轻量验证复用的小技巧：
fmt.Printf("before: %+v\n", db.Stats())
for i := 0; i < 5; i++ {
go func() { db.QueryRow("SELECT 1") }()
}
time.Sleep(100 * time.Millisecond)
fmt.Printf("after: %+v\n", db.Stats())如果 Idle 下降、InUse 上升，之后又回升，说明复用生效；否则就是池没起作用。
事务不提交，连接就永远卡住
*sql.Tx 不是连接池的一部分，但它从池里借走的连接不会自动还回去。忘了 tx.Commit() 或 tx.Rollback()，那个连接就一直被占着，SetConnMaxLifetime 对它完全无效——因为连接还在“使用中”，超时逻辑压根不触发。
后果很直接：db.Stats().InUse 慢慢涨到顶，新请求全在排队，直到超时。
实操建议：
- 所有事务块必须配对
defer tx.Rollback()+ 显式tx.Commit()，不能只靠 defer - 避免在 HTTP handler 里开事务后直接 return，中间任何 error 都要确保 rollback
- 用静态检查工具（如
errcheck）扫tx.Commit()和tx.Rollback()是否被忽略
连接池不是设完参数就一劳永逸的事。最危险的坑，往往藏在“看起来运行正常”的几小时之后——Idle 连接堆着不动，事务泄漏缓慢累积，监控指标安静得像没出事。真出问题时，不是报错，而是延迟慢慢变长、QPS 无声下滑。
