ORM无法自动识别读写语义，因database/sql与GORM均不解析SQL语法，仅作字节流传输；SELECT ... FOR UPDATE等语句需主库执行，正则匹配易误路由至只读从库报错；关联查询、延迟加载等隐含写语义，无法靠关键字判断。
为什么不能依赖 ORM 自动识别读写语义
database/sql 和主流 ORM（如 GORM）都不解析 SQL 语义，SELECT ... FOR UPDATE、INSERT ... SELECT 或带 WITH RECURSIVE 的查询，在驱动层只是字节流。正则匹配“SELECT”就发往从库，大概率在从库报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
常见错误包括：
- 用
dbresolver配置后，误以为所有非事务SELECT都安全——但SELECT COUNT(*) FROM orders WHERE status = 'pending' FOR UPDATE必须走主库 - GORM 的
ReadOnly: truesession 无法覆盖锁语义，仍可能被路由到从库并失败 - ORM 自动生成的关联查询（如
Preload("Profile")）可能隐含写语义或触发延迟加载，无法靠前缀判断
如何初始化两个独立的 *sql.DB 实例并避免连接池污染
主库和从库不是“同一配置换地址”，而是负载特征完全不同的端点：主库写多、延迟敏感；从库读多、可容忍抖动。共用 sql.Open() 返回值或浅拷贝指针会导致连接池参数错配、健康状态混淆。
必须分开初始化：
立即学习“go语言免费学习笔记（深入）”；
- 主库：
masterDB, _ := sql.Open("mysql", "user:pass@tcp(10.0.1.10:3306)/mydb")，随后调用masterDB.SetMaxOpenConns(25)、masterDB.SetWriteTimeout(2 * time.Second)、masterDB.SetConnMaxLifetime(5 * time.Minute) - 从库：
slaveDB, _ := sql.Open("mysql", "user:pass@tcp(10.0.2.20:3306)/mydb")，单独设slaveDB.SetMaxOpenConns(120)、slaveDB.SetReadTimeout(8 * time.Second)、slaveDB.SetConnMaxLifetime(15 * time.Minute) - 每个实例都需显式
db.Ping()；主库失败应 panic，从库可异步重试但首次读前必须校验 - HTTP 服务中，
defer db.Close()必须放在 shutdown 阶段统一执行，否则测试或 CLI 场景易泄漏
事务内混用主从库的典型错误现象
最危险的不是报错，而是数据不一致：事务里用 slaveDB.QueryRow() 查旧值，再用 masterDB.Exec() 更新，业务逻辑基于过期快照决策。
错误写法示例：
tx, _ := masterDB.Begin()
// ❌ 错误：这不是事务内查询，是另一个独立会话
_ = slaveDB.QueryRow("SELECT balance FROM accounts WHERE id = $1", 123).Scan(&bal)
tx.Exec("UPDATE accounts SET balance = $1 WHERE id = $2", bal-100, 123)
tx.Commit()
正确做法只有两种：
- 事务内所有操作必须用
tx对象：tx.QueryRow(...)、tx.Exec(...)，且tx只能来自masterDB.Begin() - 若需强一致性读+写分离，应把读操作提前到事务外，用
masterDB.QueryRow()获取最新值，再开启事务
注意：*sql.Tx 不是通用查询句柄，它绑定的是创建它的 *sql.DB 实例，无法跨实例复用。
从库选型必须考虑复制延迟与健康状态
简单随机或轮询选从库，容易把流量打到已断连、或 Seconds_Behind_Master > 10 的节点上。Go 没有开箱即用的带延迟感知的负载均衡器，得自己维护状态。
实际可行方案：
- 为每个从库维护字段：
isHealthy bool（心跳检测结果）、lastReplicationLag int（秒级）、weight int（静态权重） - 每次读请求前过滤：
!isHealthy || lastReplicationLag > 10的节点直接剔除 - 剩余节点按
weight加权随机选择，而非纯随机 - 定期异步刷新状态（如每 5 秒执行
SHOW SLAVE STATUS），避免阻塞主请求线程
别在 Query() 方法里自动 fallback 到主库——这会让从库故障静默，掩盖真实问题。健康检查和降级开关必须分离设计。
