下单接口写完立刻回查订单详情，返回 404，重试一次才有。从库的 Seconds_Behind_Master 显示 0，实际延迟有 40 毫秒。乍看像缓存或者权限的锅，追下去往往不是。
SHOW SLAVE STATUS\G
SELECT MASTER_POS_WAIT('mysql-bin.000123', 456789, 1);
追下去是这么回事：写完走主库、读走从库，中间隔着 relay log 的应用时间，这个窗口里从库看不到新行。Seconds_Behind_Master 只反映 SQL 线程落后 relay log 的距离，网络和应用之间的空档它测不出来。
碰到「主从读到旧数据」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
具体做法是，下单后的详情查询强制走主库 至少在一个会话里保持一致；用 GTID 做会话级读一致性 等从库追上再读；把写后立即读的场景列出来 前端不要刚提交就跳详情；监控改成对比主从位点差 别只看 Seconds_Behind_Master。
验收就看一点，下单后立刻查询能拿到数据 压测里没有 404 主从位点差稳定在毫秒级。