GORM v2 中需先调用 gormDB.DB() 获取底层 sql.DB 实例，再对其调用 SetMaxOpenConns 才生效；直接对 gorm.DB 调用无效，否则连接池配置不生效，易导致 MySQL 连接数超限或泄漏。
直接调 SetMaxOpenConns 不生效？因为没拿到底层 *sql.DB
很多人在 GORM 初始化后写 gormDB.SetMaxOpenConns(50)，发现完全没效果——gorm.DB 类型根本没有这个方法。GORM v2 的 *gorm.DB 是封装体，连接池参数必须透传到底层的 *sql.DB 实例上。
正确路径是：sqlDB, err := gormDB.DB()，再对 sqlDB 调用 SetMaxOpenConns。漏掉这一步，所有配置都只是“写进空气”。
常见错误现象：
- 日志里看到
db.Stats().MaxOpenConnections始终是 0（即默认无上限） - MySQL 持续报
ERROR 1040: Too many connections，但 Go 侧db.Stats()显示OpenConnections却不高——说明连接没被池管理，而是每次新建又泄漏
SetMaxOpenConns 可以运行时改，但有副作用
Go 的 *sql.DB 允许在运行时多次调用 SetMaxOpenConns，它会立即生效：新请求受新限制约束，已有连接不受影响，也不会被主动关闭。
但要注意三点：
- 调小值（如从 100 → 20）会导致后续获取连接的 goroutine 立即排队，
db.Stats().WaitCount和WaitDuration会跳升，P95 延迟可能陡增 - 调大值（如从 20 → 200）不会自动建新连接，只放宽上限；空闲连接数仍受
SetMaxIdleConns约束，不会立刻“补满” - 如果当前
OpenConnections已超新设上限（比如原设 100，当前用了 120，再设成 80），已建立的连接继续工作，但新请求会开始排队或失败
动态调整前必须检查 SetMaxIdleConns 是否越界
Go 1.12+ 对参数做了硬校验：SetMaxIdleConns(n) 若大于当前 MaxOpenConns 值，会 panic 并报错 "max idle conns exceeds max open conns"。
所以哪怕你只想改 MaxOpenConns，也得先确认 MaxIdleConns 是否合规：
- 先读当前值：
stats := db.DB().Stats()，看stats.MaxOpenConnections和stats.MaxIdleConnections - 若要设
SetMaxOpenConns(30)，必须确保SetMaxIdleConns≤ 30；若当前是 50，就得先SetMaxIdleConns(30)，再SetMaxOpenConns(30) - 顺序不能反：先扩
MaxOpenConns再扩MaxIdleConns安全；反过来大概率 panic
为什么线上不建议频繁动态调参
连接池参数不是开关，而是资源水位线。动态调参解决不了根本问题：
- 临时扩容掩盖了慢查询、事务未提交、
rows.Close()漏写等真实泄漏源 - 调参后无法自动触发已有空闲连接的清理，失效连接仍滞留在池中，直到下次复用才暴露
i/o timeout或invalid connection - 真正需要响应式伸缩的场景（如突发流量），靠手动调参太滞后；应优先用
SetConnMaxLifetime+SetConnMaxIdleTime让连接自然轮换
最常被忽略的不是“能不能调”，而是调完之后没人去看 db.Stats() —— 连接数、等待数、空闲数、存活时间，这些指标不盯紧，调参等于蒙眼开车。
