MySQL 读写分离延迟：读库不是主库的实时镜像

读写分离是后端架构常见优化：写走主库，读走从库，降低主库压力。但读库不是主库的实时镜像。复制延迟一旦出现，用户刚写完数据马上读，就可能读到旧值。这个问题在订单、权限、配置、AI 任务状态里都很敏感。

读写分离不能只看吞吐，还要设计一致性体验。

一、复制延迟是常态风险

sequenceDiagram participant App participant Primary participant Replica App->>Primary: Write Primary-->>App: Success Primary->>Replica: Replication App->>Replica: Read Replica-->>App: Old Data

写成功只代表主库提交，不代表从库已经追上。延迟可能来自大事务、网络、从库 IO 或 SQL 线程压力。

二、关键读走主库

写后立刻读的场景，可以短时间走主库。

read_policy: after_write_window: 3s critical_resource: primary normal_list_page: replica

不是所有读都要强一致。关键是把需要强一致的场景识别出来。

三、监控复制延迟

SHOW REPLICA STATUS;

关注Seconds_Behind_Source只是开始，还要结合 relay log、IO thread、SQL thread 状态。延迟指标也要进入应用路由策略。

四、任务状态别乱走读库

AI 后台任务状态、支付状态、权限变更这类强依赖最新值的读，不适合默认走从库。否则用户会看到任务完成后页面还显示处理中。

strong_read_tables: - payment_order - ai_job_status - user_permission

架构上可以给 DAO 或 repository 标记一致性等级，而不是让业务代码随手选数据源。

还可以在写入后设置短期一致性标记。比如用户刚更新资料，接下来几秒内该用户相关读取走主库。这样不必让所有请求都走主库，也能保护写后读体验。

read_after_write: key: user_id ttl: 3s route: primary

这种策略要谨慎控制范围，否则会把主库读压力重新打满。

五、总结

MySQL 读写分离能提升读能力，但读库不是主库实时镜像。写后读、任务状态、权限、支付等场景要考虑强一致读取。

读写分离不是把所有 SELECT 扔给从库。知道哪些读不能分，才是成熟架构。

复制延迟不可怕，可怕的是业务假装它不存在。把一致性等级显式写进代码，团队才知道自己在做什么取舍。

读路由还要支持紧急切换。当从库延迟超过阈值时，关键读自动回主库，普通读可以降级或提示稍后刷新。

replica_lag_policy: warn_at: 1s strong_read_to_primary_at: 2s disable_replica_at: 5s

这会增加主库压力，所以阈值要谨慎。但没有策略，就只能在事故中手动改配置。

还要给用户体验留解释。比如刚提交的配置还在同步中，可以提示“更新已保存，部分页面可能稍后刷新”。这比让用户看到旧数据却没有解释更好。

user_feedback: write_success: "已保存" replica_lag_hint: "数据同步中，请稍后刷新" force_primary_for_detail: true

当然，支付、权限、任务状态这类核心链路不要靠提示解决，应该直接强一致读取。提示只能用于低风险体验场景。