SetMaxOpenConns必须设为数据库max_connections的60%～80%（如200则设120～160），不可为0或随意设值；SetMaxIdleConns须≤其值，推荐设为1/2～2/3，并配合SetConnMaxLifetime（2～5分钟）和SetConnMaxIdleTime防陈旧连接；需用db.Ping()验证初始连通性，再通过db.Stats().InUse、Idle、WaitCount持续监控调优。
SetMaxOpenConns 必须设，不能为 0 或拍脑袋定
默认值 SetMaxOpenConns=0 表示无上限，上线后 MySQL 很快报 Too many connections，P99 延迟可能从 50ms 拉到 800ms+。这不是代码慢，是连接池和数据库“呼吸节奏”没对上。
正确做法是先查数据库真实容量：
SHOW VARIABLES LIKE 'max_connections';
假设返回 200，那就设 SetMaxOpenConns 为 120～160（60%～80%），留余量给备份、监控和其他服务。云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机配置。
- 设成
500：MySQL 立即拒绝新连接，错误日志刷屏Too many connections - 设成
10：20 个 goroutine 并发查用户，全卡在等连接，QPS 上不去，平均延迟反而升高 - 用
db.DB().SetMaxOpenConns(n)，不是gorm.Open的参数——GORM 不接管连接池，只透传底层*sql.DB
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对用
只调 SetMaxIdleConns 不设 SetConnMaxLifetime，等于让空闲连接赖着不走。云环境 NAT 网关或防火墙会在 3～5 分钟后静默断连，下次复用直接报 read: connection reset by peer。
立即学习“go语言免费学习笔记（深入）”；
推荐组合：
-
SetMaxIdleConns设为SetMaxOpenConns的 1/2 到 2/3（例如最大 100 → 空闲设 40～60） -
SetConnMaxLifetime推荐 2～5 分钟：云数据库主备切换快，设 2 分钟更安全；自建 MySQL 可设 5 分钟 - 千万别设成
0或time.Hour：长期存活连接容易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
注意：SetMaxIdleConns(n) 若大于当前 SetMaxOpenConns 值，Go 1.12+ 会直接 panic，错误信息为 "max idle conns exceeds max open conns"。务必先设 MaxOpenConns，再设 ≤ 它的 MaxIdleConns。
db.Ping() 不是可选动作，是启动必检项
sql.Open() 或 gorm.Open() 只是初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致线上首屏白屏。
必须紧接 db, err := gorm.Open(...) 后加：
if err := db.Ping(); err != nil {
log.Fatal("failed to ping DB:", err)
}
注意：db.Ping() 只验证“此刻能建一个连并执行 SELECT 1”，它不检查池中已有空闲连接是否还活着。数据库侧（如 MySQL wait_timeout=300）主动断连后，连接仍躺在池里，直到下次被取出执行 Query() 才暴露 invalid connection 或 i/o timeout。所以 k8s readiness probe 若只调 db.Ping()，可能误判服务可用。
连接池参数不是一锤子买卖，得靠 db.Stats() 持续观察
调参后不看指标，等于蒙眼开车。启动后应定期打点 db.Stats()，重点关注三个字段：
-
InUse：是否长期 >95%，说明连接不够用，得调高MaxOpenConns -
Idle：是否长期接近 0，说明连接复用率低或生命周期太短 -
WaitCount：是否持续上涨，代表请求排队严重，连接池已成瓶颈
这些值波动大、趋势异常时，才是真该调参的时候。别依赖压测一次性定死——流量毛刺、DB 主备切换、中间件升级都可能让旧参数失效。
