gorm.open后必须立即调用db.db()获取sql.db才能设置连接池参数，因gorm自身配置不控制连接池；需分别对主从库的sql.db调用setmaxopenconns等方法，并打印stats验证生效。
gorm.Open 之后必须立刻获取 *sql.DB 才能调用 SetMaxOpenConns
很多人在 Gin 初始化数据库时，把连接池参数写在 gorm.Open 的 &gorm.Config{} 里，结果发现根本没生效——因为 GORM 的连接池控制不在它自己配置里，而在底层的 *sql.DB 实例上。
正确做法是：先调 gorm.Open 得到 *gorm.DB，再用 db.DB() 拿到原生 *sql.DB，最后设置连接池参数。
-
sqlDB.SetMaxOpenConns(100)：控制最大打开连接数，超了会阻塞或报错（取决于上下文） -
sqlDB.SetMaxIdleConns(20)：空闲连接上限，设太小会导致频繁建连；设太大可能被 MySQL 服务端 kill（如 wait_timeout 触发） -
sqlDB.SetConnMaxLifetime(1h)：连接最长存活时间，避免因网络抖动或服务端主动断连导致 stale connection
事务内连接池行为与超时风险
Gin 处理 HTTP 请求时，若在 handler 中开启事务（db.Begin()），该事务会独占一个连接直到 Commit() 或 Rollback()。如果连接池已满且所有连接都在事务中，后续请求就会卡在 db.DB().Conn() 上，表现为接口超时、CPU 低但响应停滞。
常见诱因：
- 忘记
defer tx.Commit()或漏写tx.Rollback()错误分支 - 事务内调用了耗时操作（如 HTTP 请求、文件读写），拖长连接占用时间
-
SetMaxOpenConns设得过小（如 5），而并发请求 > 5 且含事务
建议：对非强一致性读，尽量用普通查询；事务只包裹真正需要原子性的 DB 操作段。
多数据源场景下连接池要分开配
如果你用 dbresolver 做读写分离，主库和从库的连接池必须各自独立设置——dbresolver.Register() 返回的是一个代理 *gorm.DB，它内部持有多个子 *gorm.DB，每个子 DB 都要单独调 .DB() 并设置池参数。
错误写法：db.DB().SetMaxOpenConns(100) 只影响主库，从库仍用默认值（通常是 0，即无限制）。
正确顺序：
- 分别调
gorm.Open创建主库masterDB和从库slaveDB - 各自调
masterDB.DB().SetMaxOpenConns(...)和slaveDB.DB().SetMaxOpenConns(...) - 再用
dbresolver.Register(masterDB, slaveDB)注册到主*gorm.DB
连接池参数没有“标准值”，得看你的部署环境
本地开发用 SetMaxOpenConns(10) 没问题，但上线后往往要调高。实际值取决于：
- 你的 Gin 实例数（单实例 vs 多 worker 进程）
- MySQL 服务端的
max_connections设置（别让所有 Go 实例加起来超这个数） - 平均请求耗时（越慢，连接被占时间越长，需要更多连接）
- 是否启用了连接复用（如 HTTP/2、长连接客户端）
最容易被忽略的一点：Gin 启动时没打印连接池状态，你得自己加日志，比如在 InitDatabase() 末尾补一句 log.Printf("DB pool: maxOpen=%d, maxIdle=%d", sqlDB.Stats().MaxOpenConnections, sqlDB.Stats().Idle)，否则永远不知道配没配成功。
