MySQL从库读到旧数据是因主从异步复制导致SQL_THREAD应用relay log存在延迟，属默认行为而非bug；强一致读需GTID、ROW格式等配置前提，并须配合超时降级策略。
为什么从库会读到旧数据
MySQL 主从复制是异步的，从库 SQL_THREAD 应用 relay log 有延迟，哪怕只有几十毫秒，应用层发起读请求时，刚好落在主库写入后、从库还没追上的窗口期，就会读到过期数据。这不是 bug，是默认行为——READ-COMMITTED 或 REPEATABLE-READ 隔离级别下，从库只保证自身事务一致性，不保证和主库实时同步。
常见错误现象：INSERT 到主库后立刻 SELECT 从从库查不到；订单创建成功但列表里没出现；缓存穿透后回源读从库，返回空导致反复回源。
强制从库强一致读的三种可行方式
没有全局开关一键开启“强一致读”，必须按场景选方法，每种都有代价：
- 用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE：仅对 InnoDB 表有效，会触发从库等待SQL_THREAD追上当前事务的 GTID（需启用gtid_mode=ON），但会阻塞、影响并发，不适合高频查询 - 在客户端显式指定
MASTER_POS_WAIT()：适用于已知主库 binlog 位置的场景，比如刚执行完INSERT并拿到SHOW MASTER STATUS结果，调用SELECT MASTER_POS_WAIT('xxx', xxx)等待从库追上，超时需降级处理 - 改用
SELECT ... FROM tbl AS OF TIMESTAMP '2024-06-15 10:20:30'（MySQL 8.0.23+）：底层基于 replica lag 检测 + 自动等待，但要求开启replica_preserve_commit_order=ON且从库无并行复制冲突，否则可能报错ER_REPLICA_NOT_RUNNING
绕不开的配置前提
所有强一致读方案都依赖几个关键配置，缺一不可：
- 主库必须开启
binlog_format=ROW，语句模式（STATEMENT）无法准确定位事务边界 - 主从必须启用 GTID（
gtid_mode=ON+enforce_gtid_consistency=ON），否则MASTER_POS_WAIT()和时间点查询无法工作 - 从库需关闭
slave_parallel_workers > 0或启用slave_preserve_commit_order=ON，否则事务提交顺序乱序，强一致等待逻辑失效 -
read_only=ON在从库上必须为真，否则应用误写从库会导致 GTID 不一致，后续等待永远卡住
最容易被忽略的坑：应用层没做 fallback
强一致读不是银弹。网络抖动、从库宕机、SQL_THREAD 延迟突增几十秒，都会让 MASTER_POS_WAIT() 超时或 AS OF TIMESTAMP 报错 ER_GTID_WAIT_TIMEOUT。这时候如果代码没设超时、没切主库或本地缓存兜底，请求就直接失败。
实操建议：
- 所有强一致读调用必须带
timeout参数，例如MASTER_POS_WAIT('xxx', xxx, 2)最多等 2 秒 - 超时后立即降级为普通从库读（不加任何等待），同时打日志告警，而不是重试或抛异常
- 不要在事务内混合使用强一致读和普通读——前者等位置，后者可能读到更旧状态，逻辑自相矛盾
真正难的不是加一行 AS OF TIMESTAMP，而是判断哪条读必须强一致、哪条可以容忍几秒延迟，以及当它失败时系统是否还能稳住。
