主从延迟导致读不到新数据本质是读了过期从库，因mysql主从异步复制；关键在区分强一致读（如查刚下订单）与最终一致读（如统计pv），并按契约选择读主、事务绑定或缓存兜底。
主从延迟时读不到新数据，本质是读了过期的从库
MySQL 主从复制是异步的，写入主库后，从库需要时间拉取并重放 binlog。业务如果直接读从库，就可能查不到刚插入或更新的数据——这不是 bug，是架构设计决定的。关键不是“怎么消除延迟”，而是“哪些读必须绕过从库”。
判断是否真需要强制读主：看业务一致性要求
不是所有读都要强一致。比如用户发完评论立刻刷新看自己评论，这种场景必须读主；但首页推荐位统计昨日 PV，差几秒完全可接受。混淆这两类会导致过度降级、主库压力飙升。
-
强一致读场景：用户刚提交订单查订单列表、修改密码后立即登录、支付成功后查支付状态 -
最终一致读场景：商品详情页浏览量、后台报表、搜索结果排序（非实时） - 常见误判：把“用户看到自己操作结果”等同于“所有用户看到同一份数据”——前者只需读自己的写路径，后者才需全局同步
强制读主的三种实操方式及坑点
不推荐在应用层硬编码 SELECT /*+ READ_FROM_MASTER */ ... 这类注释（多数中间件不识别），真正可控的是以下三种：
- 路由到主库连接池：在 DAO 层或 ORM 中，对特定方法（如
getOrderByIdAfterCreate）显式调用主库数据源，而非默认的读负载均衡池 - 事务内读主：只要当前线程存在未提交事务（哪怕只执行了
START TRANSACTION），后续SELECT默认走主库（InnoDB 下有效，注意autocommit=0的副作用） - 基于 GTID 等待从库追平：在读从库前先查
SELECT MASTER_POS_WAIT('binlog.000001', 123456789)，但该函数会阻塞，超时需 fallback 到主库，且仅适用于已知主库位点的场景
典型坑：spring @Transactional 默认传播行为是 REQUIRED，但若上层没事务，它会新建一个再提交，导致不必要的主库连接占用；更稳妥的是用 REQUIRES_NEW + 显式指定主库数据源。
延迟读取的兜底策略：用缓存代替“等从库”
与其让请求卡在 MASTER_POS_WAIT 或反复轮询 Seconds_Behind_Master，不如把刚写入的关键数据同步写入 Redis，并设置合理过期时间。读请求优先查缓存，命中则直接返回；未命中再走从库（此时延迟已消化）。
- 缓存写入时机必须和主库写入在同一事务中（用
afterCommit回调或本地消息表），否则仍有不一致风险 - 避免缓存穿透：对必然不存在的 ID（如
order_id = -1），也写入空值 + 短 TTL - 不要依赖
SHOW SLAVE STATUS的Seconds_Behind_Master做路由决策——该值可能为NULL（IO 线程断开）、突增抖动、或在并行复制下滞后计算不准
真正难的不是技术方案，而是厘清每个接口的“一致性契约”：它承诺用户多长时间内能看到变更？这个数字决定了你该用缓存兜底、事务绑定，还是干脆读主——而这个判断，没法交给中间件自动猜。
