SetMaxOpenConns必须与批量写入峰值对齐，估算公式为“峰值批量并发数×每批平均耗时（秒）×1.2”，严禁设0；SetMaxIdleConns应设为SetMaxOpenConns的1/2～2/3，SetConnMaxLifetime需配对设为2～5分钟防stale连接；批量任务前必须db.Session().Ping()校验连接，且大批量写入应绕过GORM直连*sql.DB+Prepare优化。
SetMaxOpenConns 必须和批量写入峰值对齐
批量更新（比如 CreateInBatches 或 Updates）会在短时间内集中消耗连接，若 SetMaxOpenConns 还按常规查询流量设（如 50），很容易卡在连接等待上，表现就是 P99 延迟陡升、日志里反复出现 waiting for connection。
- 估算公式：取「峰值批量并发数 × 每批平均耗时（秒）」再加 20% 缓冲；例如每秒跑 10 批、每批耗时 0.3s → 基线约 3 连接，但实际要设到 80～120（留足余量防毛刺）
- 绝不能设为 0：等于放任连接数冲到 MySQL 的
max_connections上限，直接触发Too many connections - 云数据库（如阿里云 RDS）建议更保守：按 CPU 核数 × 20 估算上限，别照搬物理机配置
SetMaxIdleConns 和 SetConnMaxLifetime 必须配对调
批量任务结束后常有大量连接空闲，若只调大 SetMaxIdleConns 却不设 SetConnMaxLifetime，这些空闲连接会在云环境 NAT 或防火墙超时后被静默断开，下次复用就报 read: connection reset by peer。
-
SetMaxIdleConns设为SetMaxOpenConns的 1/2 到 2/3（例如 Open=100 → Idle=40～60） -
SetConnMaxLifetime设为 2～5 分钟：云数据库主备切换快，2 分钟更安全；自建 MySQL 可设 5 分钟 - 严禁设为 0 或
time.Hour：长期存活连接易在 DB 侧积压idle in transaction，锁资源、占内存、拖慢其他查询
db.Ping() 不是可选项，是批量任务前的必检动作
gorm.Open() 只初始化结构，不建真实连接。批量更新启动时若网络不通、密码错或 DNS 解析失败，所有 goroutine 会一起卡在首请求上——轻则超时，重则服务雪崩。
- 必须在
gorm.Open()后立刻调用：db.Session(&gorm.Session{}).Ping()（GORM v2 中db.Ping()已弃用） - 检查 error 并 panic 或重试，不能忽略
- 若用
CreateInBatches，还要注意它默认不开启事务：某批失败时前面批次已提交，务必手动包db.Transaction()
大批量写入时，GORM 连接池只是起点，不是终点
当单次写入超 10 万行、或要求毫秒级延迟（如日志归集、CDC 同步），GORM 的抽象层反而成瓶颈。这时候连接池调得再好也没用，因为 SQL 构建、参数绑定、结果扫描本身就在吃 CPU 和内存。
- 绕过 GORM，直连
*sql.DB+Prepare+ 循环Exec，避免每次解析 SQL - 慎用
db.Create(&users)（users是切片）：GORM v2 默认仍按单条处理，必须显式用CreateInBatches(users, 500) - 注意主键回填限制：MySQL 不支持
RETURNING，插入后users[0].ID仍是 0；PostgreSQL 支持但仅限单批
批量更新场景下，连接池参数不是孤立配置项，它和事务控制、SQL 生成方式、甚至是否该绕过 ORM 都紧密耦合。最容易被忽略的是：**调完池子不验证、不包事务、还指望 GORM 自动扛住十万级写入——这三件事少做一件，线上就容易出 silent failure。**
