SetMaxOpenConns应设为MySQL max_connections的60%～80%（如200则设120～160），并配对设置SetMaxIdleConns（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%）。留余量给备份、监控、其他服务，也防突发毛刺。
- 设成
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 := sql.Open(...)，同样要db.Ping()，否则无法提前暴露底层驱动问题 - 配合
db.Stats()定期打点：重点关注InUse（是否长期 >95%）、Idle（是否长期接近 0）、WaitCount（是否持续上涨）
GORM v2 初始化后连接池参数得手动设，不是自动继承
GORM v2 的 gorm.Open() 返回的是 *gorm.DB，它底层封装了 *sql.DB，但连接池参数不会自动透传。你得显式拿到 *sql.DB 实例再设置：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
panic(err)
}
sqlDB, err := db.DB() // 获取底层 *sql.DB
if err != nil {
panic(err)
}
sqlDB.SetMaxOpenConns(120)
sqlDB.SetMaxIdleConns(60)
sqlDB.SetConnMaxLifetime(3 * time.Minute)
if err := db.Ping(); err != nil {
panic(err)
}注意：v2 中没有 gorm.Open("mysql", dsn) 这种写法，必须用驱动包的 mysql.Open(dsn)；且 SetConnMaxIdleTime（Go 1.15+）可选，但 SetConnMaxLifetime 更关键，优先保证。
调参不是一锤子买卖，上线后得盯 db.Stats() 和数据库侧的 Threads_connected，连接池和 DB 的“呼吸节奏”没对上，问题一定出在这几行代码上。
