SetMaxOpenConns应设为数据库max_connections的60%～80%，如MySQL返回200则设120～160，留余量给备份监控；过高触发Too many connections，过低导致请求排队，须配合SetMaxIdleConns和SetConnMaxLifetime协同调优。
连接池参数不能拍脑袋设，必须和数据库服务端限制对齐，否则不是连不上就是连爆了。
SetMaxOpenConns 怎么设才不触发 Too many connections
这个值必须严格参考 MySQL 的 max_connections 配置，不是看 CPU 核数或并发量猜的。
- 查当前限制：
SHOW VARIABLES LIKE 'max_connections';，假设返回200 - 则
SetMaxOpenConns应设为120～160（60%～80%），留出余量给备份、监控、其他服务 - 云数据库（如阿里云 RDS）更保守：按每核 ≈20 连接估算，别套物理机经验
- 常见错误：
SetMaxOpenConns = 0（无限开连）、= 500（远超 DB 侧上限）、= 10（20 个 goroutine 并发就卡死）
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对用
只调 SetMaxIdleConns 不设 SetConnMaxLifetime，等于让空闲连接赖在池里不走，云环境 NAT 或防火墙会在 3～5 分钟后静默断连，下次复用直接报 read: connection reset by peer。
-
SetMaxIdleConns设为SetMaxOpenConns的 1/2～2/3（例如最大 100 → 空闲设 40～60） -
SetConnMaxLifetime推荐 2～5 分钟：2m更适合云数据库主备切换快的场景；自建 MySQL 可设5m - 千万别设成
0或time.Hour：长期存活连接容易在 DB 侧积压idle in transaction，锁资源、占内存、触发上下文切换风暴
db.Ping() 不是可选项，是启动必做动作
gorm.Open() 只初始化连接池结构，不建真实连接。很多服务日志写着 “DB initialized”，其实第一笔查询才真正拨号——这时候网络不通、密码错、DNS 解析失败，全堆在首请求上，导致首屏白屏或接口 500。
- 必须紧接
gorm.Open()后调用：db.Session(&gorm.Session{}).Ping()（GORM v2 已弃用db.Ping()） - 要检查 error，失败时应 panic 或重试，不能忽略
- 漏掉这步，K8s readiness probe 很可能误判服务健康，引发滚动更新中断
超时参数分三层，DSN 里的 timeout=5s 其实只管 TCP 建连
很多人加了 timeout=5s 就以为 SQL 执行也会超时，但实际它只控制 net.Dial 阶段，对已建立连接后的读写完全无效。
- 真正影响 SQL 执行的是：
readTimeout=30s和writeTimeout=60s，必须显式加在 DSN 里 - 连接池层面靠
SetConnMaxLifetime+SetMaxOpenConns配合防“假连接”：长连接被 DB 主动踢掉后，不清理会持续报invalid connection - 不同数据库 DSN 格式差异大：PostgreSQL 用空格分隔键值对，
sslmode=disable在本地开发必须显式写；达梦不支持charset参数，加了直接 panic
最常被忽略的其实是连接池参数和数据库服务端配置的联动关系——它们不是孤立调优项，而是一组强约束条件。设错一个，整个链路就从延迟飙升滑向连接雪崩。
