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

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