多个 gorm.DB共用一个 sql.DB会导致连接池参数互相覆盖、健康状态无法隔离，一旦某库占满连接，其他服务全卡住；必须为每个库独立sql.Open()并单独配置SetMaxOpenConns等参数。
为什么不能让多个*gorm.DB共用一个*sql.DB
多个 *gorm.DB 实例如果底层共享同一个 *sql.DB（比如通过浅拷贝或复用 db.DB() 返回值再调用 SetMaxOpenConns），会导致连接池参数互相覆盖、健康状态无法隔离。一旦某个分析型查询占满连接，API 服务就全卡住——这不是理论风险，压测时高频复现。
MySQL 主库和从库、业务库和日志库、甚至不同微服务模块的数据库，负载特征完全不同：写多读少、长事务、短查询、高并发低延迟……连接池必须按需独立配置。
- 每个数据库连接必须走独立的
sql.Open()，不能复用已有*sql.DB - 每个
*gorm.DB必须调用自己专属的db.DB().SetMaxOpenConns()等方法 - 别试图“统一管理”连接池参数——参数要按库定，不是按语言定
怎么为 MySQL 主库和从库分别配连接池
主从分离不是靠插件自动识别 SQL 类型，而是靠你显式给主库、从库各自建连接池，并在 dbresolver.Register() 里声明它们。漏掉任一环节，读请求就静默 fallback 到主库。
- 先分别用
sql.Open("mysql", dsnMaster)和sql.Open("mysql", dsnReplica)创建两个独立*sql.DB - 再分别传给
gorm.Open()得到两个原始*gorm.DB（仅用于初始化，不直接用） - 主库池参数示例：
masterSQL.SetMaxOpenConns(120)、masterSQL.SetMaxIdleConns(60)、masterSQL.SetConnMaxLifetime(2 * time.Minute) - 从库池参数通常可更激进：
replicaSQL.SetMaxOpenConns(200)（读多）、SetConnMaxLifetime(3 * time.Minute)（云环境 NAT 更严） - 最后把这两个
*sql.DB塞进dbresolver.Config{Sources: []gorm.ConnPool{masterDB}, Replicas: []gorm.ConnPool{replicaDB}}
多个业务数据库（如 user_db、order_db）怎么隔离连接池
常见错误是只建一个全局 *gorm.DB，然后靠 db.Table("order_table") 切库——这完全没隔离连接池，所有库共享同一套 SetMaxOpenConns，故障时互相拖累。
- 每个业务库定义独立 DSN，各自
sql.Open()→gorm.Open()→db.DB().SetXXX() - 避免用
db.Session(&gorm.Session{NewDB: true})伪造新实例：它仍复用原*sql.DB - 用
sync.Once包裹初始化逻辑，确保每个库只初始化一次，且池参数不被覆盖 - 检查是否真隔离：启动后打印各
db.DB().Stats()，确认OpenConnections数随各自负载变化，而非同步涨跌
云数据库（如阿里云 RDS）连接池调参要注意什么
云环境 NAT 网关、LB、数据库代理层会主动断连空闲连接，设错 SetConnMaxLifetime 或 SetConnMaxIdleTime 会导致大量 read: connection reset by peer。
- 别信“设成 0 表示永不过期”——云数据库主备切换快，连接长期存活反而容易卡在旧主节点上
- 推荐组合：
SetMaxOpenConns按每核 ≈20 连接估算（如 4 核 RDS → 80），SetMaxIdleConns设为 40～50，SetConnMaxLifetime固定 2 分钟 -
SetConnMaxIdleTime必须小于SetConnMaxLifetime，否则空闲连接永远等不到回收时机 - 自建 MySQL 可稍宽松，但也要禁用
time.Hour这类值：DB 侧会积压idle in transaction，锁资源、吃内存
真正容易被忽略的是：连接池隔离不是“开了多个 db 变量”就自动生效的。每个 <em>gorm.DB</em> 必须有自己专属的 sql.DB 底层实例，且所有 SetXXX 调用都必须作用于该实例。漏掉任意一层，就等于把不同负载的车轮装在同一根传动轴上——跑得越快，崩得越突然。
