直接用sql.Open配置多个DSN会出问题，因database/sql不支持读写分离，事务中混用主从库导致数据不一致或原子性破坏；sql.Tx只能绑定单一sql.DB，无法跨库切换，且延迟敏感场景需强一致读直连主库，不能依赖SQL解析路由。
为什么直接用 sql.Open 配置多个 DSN 会出问题
Go 的 database/sql 包本身不支持读写分离逻辑，sql.Open 只能绑定单个 DSN。如果手动维护两个 *sql.DB 实例（一个主库、一个从库），在事务中混用会导致数据不一致：比如 INSERT 写主库后立刻 SELECT 从从库查，可能因主从延迟读不到最新数据；更严重的是，事务内跨 DB 操作根本无法保证原子性——*sql.Tx 只能绑定到单一 *sql.DB。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要在业务层硬编码“主库写 / 从库读”分支，避免每个 DAO 方法都加
if isWrite { useMaster() } else { useSlave() } - 用封装好的数据库代理层（如
gofr的DBRouter或自研ReadWriteDB）统一拦截Query/Exec调用，按 SQL 类型或上下文自动路由 - 对显式开启的事务（
db.Begin()），强制走主库，且整个*sql.Tx生命周期内禁止切换 DB 实例
如何让 SELECT 自动打到从库，但跳过延迟敏感场景
不是所有 SELECT 都适合走从库。比如用户刚注册完立即查个人资料、支付成功后查订单状态，这类强一致性读必须直连主库，否则可能返回空或旧数据。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在调用链入口（如 HTTP handler 或 gRPC method）通过 context 注入读策略：
ctx = context.WithValue(ctx, "read_preference", "strong") - 数据库代理层检查 context 中的
read_preference：值为"strong"时强制使用主库；未设置或为"eventual"时才考虑从库 - 对带
FOR UPDATE、LOCK IN SHARE MODE的SELECT，一律路由到主库——MySQL 从库默认不支持写锁 - 避免依赖 SQL 解析判断读写类型（如正则匹配
^SELECT），因为SELECT ... INTO @var或子查询中的SELECT可能隐含写语义
主从同步延迟怎么测，又怎么触发重试或降级
不能靠固定 sleep 或经验预估延迟。真实延迟受 binlog 格式、网络抖动、从库负载影响，可能几毫秒，也可能数秒。关键是要有实时探测能力，并与业务逻辑联动。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在从库执行
SHOW SLAVE STATUS，提取Seconds_Behind_Master字段，但注意该值在 IO 线程异常时可能为NULL或0（误报） - 更可靠的方式是写入主库时带上当前时间戳（如
INSERT INTO heartbeat(ts) VALUES (NOW(3))），再从从库查该记录的ts与本地时间差，作为真实延迟基准 - 当延迟 > 500ms 且持续 3 次探测超标，自动将该从库实例从负载均衡池剔除（更新连接池中的可用节点列表）
- 对强一致性读请求，若探测到延迟超标，可 fallback 到主库查询，但需记录日志并告警——这说明主从同步链路已不稳定
为什么 sqlx 或 gorm 的原生方法不解决主从问题
sqlx 是 database/sql 的增强封装，gorm 是 ORM 层，它们都工作在 *sql.DB 之上。只要底层没提供多数据源抽象，上层再怎么封装也无法自动路由读写流量。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要试图用
gorm.Config.ConnPool配多个*sql.DB——gorm.DB实例只持有一个连接池 - 如果坚持用
gorm，需自己实现gorm.Dialector，在Open和QueryContext中注入路由逻辑，但这会绕过 GORM 大量内置优化（如预编译、缓存） - 更务实的做法是：DAO 层用原生
database/sql+ 自研路由代理，复杂查询逻辑用sqlx辅助构建，但绝不让它接管连接池 - 特别注意
gorm.Session(&gorm.Session{NewDB: true})这类 API，它创建新*gorm.DB实例，若未显式指定连接池，会继承父实例的主库连接池，导致读请求意外走到主库
主从同步校验不是一次配置就能高枕无忧的事，延迟探测的采样频率、超时阈值、fallback 后的错误码设计，都得贴着具体业务的容忍度来调。最容易被忽略的是：应用重启时，从库健康检查状态丢失，需要主动触发一次初始化探测，否则可能把流量导到已掉线的从库上。
