写入主库后立刻从副本读取，可能看不到刚刚提交的记录。复制链路存在延迟。
本文使用MySQL 5.6、InnoDB 与独立测试数据库。数据库研究要同时观察表结构、数据分布和实际语句。本文讨论 InnoDB（事务存储引擎），不把其他存储引擎或后续版本特性当作相同行为。
1. 从现象推到机制
异步复制需要把主库变更传输并在副本应用，网络与执行速度都会影响进度。读写分离增加读取入口，却不自动提供写后读一致性。单个延迟指标也不足以证明目标事务已经应用。
图中的四个节点分别表示主库提交、日志传输、副本应用、读取路由。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
用主库写一条演示记录，再分别访问主库和副本。需要强写后读的页面可在有限范围路由主库，并明确连接池和读路由策略。
1
2
3
4
-- 主库提交后，分别在两个入口查询同一业务键
SELECT id, status FROM orders WHERE id=:id;
-- 副本诊断入口
SHOW SLAVE STATUS;
先保存建表语句、索引与隔离级别，再准备固定演示数据。并发行为使用两个独立连接按顺序执行；执行计划、锁等待和最终数据需要结合，单看查询耗时不足以解释原因。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 副本执行变慢 | 读结果可能落后于主库 |
| 写后立即改读副本 | 可能出现刚创建却查不到 |
| 延迟指标看似为零 | 仍需核对目标事务与来源 |
对照 1：副本执行变慢
读结果可能落后于主库。观察时记录复制应用位置与目标记录。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：写后立即改读副本
可能出现刚创建却查不到。观察时记录读连接真实指向。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：延迟指标看似为零
仍需核对目标事务与来源。观察时记录复制状态和具体数据证据。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
副本用于读取扩展或恢复，各自有运维要求。不能把复制直接当成备份，因为误删和错误更新也可能被复制。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“延迟指标看似为零”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
