SetMaxOpenConns应设为MySQL max_connections的60%～80%（如后者为200，则设120～160），预留余量防毛刺并兼顾备份监控；须配对设置SetMaxIdleConns（为Open值的1/2～2/3）和SetConnMaxLifetime（云环境推荐2～5分钟），且启动时必须调db.Ping()验证连接，否则首请求易失败。
SetMaxOpenConns 怎么设才不爆 Too many connections
这个值必须和数据库的 max_connections 对齐，不能拍脑袋。查 MySQL 当前限制：
SHOW VARIABLES LIKE 'max_connections';
假设返回 200，SetMaxOpenConns 就该设成 120～160（60%～80%）。留余量给备份、监控、其他服务，也防突发毛刺。
常见错误：
-
SetMaxOpenConns设为0或500：MySQL 很快报Too many connections，P99 延迟从 50ms 拉到 800ms+ - 设太低（比如
10）：20 个 goroutine 并发查用户，全卡在等连接，QPS 上不去，平均延迟反而升高 - 云数据库（如阿里云 RDS）建议更保守：按每核 ≈20 连接估算，别硬套物理机配置
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对用
只调 SetMaxIdleConns 不设 SetConnMaxLifetime，等于让空闲连接一直赖着不走。云环境 NAT 网关或防火墙会在 3～5 分钟后静默断连，下次复用直接报 read: connection reset by peer。
推荐组合：
-
SetMaxIdleConns设为SetMaxOpenConns的 1/2 到 2/3（例如最大 100 → 空闲设 40～60） -
SetConnMaxLifetime推荐 2～5 分钟：云数据库主备切换快，设 2 分钟更安全；自建 MySQL 可设 5 分钟 - 千万别设成
0或time.Hour：长期存活连接容易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
为什么启动时漏掉 db.Ping() 会导致首屏白屏
sql.Open() 或 gorm.Open() 只是初始化连接池结构，不建真实连接。很多服务日志里写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上。
必须紧接 db, err := gorm.Open(...) 后面加 db.Ping()，并检查 error：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
log.Fatal(err)
}
if err := db.Session(&session).Ping(); err != nil { // 注意：v2 中 db.Ping() 已被弃用，应转用 db.Session(&gorm.Session{}).Ping()
log.Fatal("failed to ping database:", err)
}
若用 sql.DB 初始化，同样要 db.Ping()，否则无法提前暴露底层驱动问题。
怎么用 db.Stats() 监控连接池健康度
调参不是一锤子买卖。上线后得靠 db.Stats() 定期打点，重点关注三项：
-
InUse：是否长期 >95%，说明连接不够用或有连接泄漏 -
Idle：是否长期接近 0，说明连接池没复用起来，或SetMaxIdleConns太小 -
WaitCount：是否持续上涨，代表 goroutine 在排队等连接，是SetMaxOpenConns不足的强信号
最易被忽略的是：连接池参数和数据库 max_connections 的比例关系，以及 SetConnMaxLifetime 和云环境网络超时的匹配——这两个点没对齐，线上故障往往来得又急又哑。
