主从延迟需从业务、架构、运维协同治理：按强一致、会话级一致、最终一致分级读策略；优化主库高危操作（拆大事务、ddl避峰、从库资源隔离）；实现延迟感知路由、写后主库读、缓存兜底；建立延迟监控、链路追踪与慢同步定位机制。
主从延迟不是纯技术问题，而是业务、架构、运维三者交织的结果。解决它不能只盯着 MySQL 参数调优或加从库，得从“哪些读必须强一致”“哪些读可以等”“哪些读根本不用走数据库”开始分层处理。
按业务场景分级一致性策略
一刀切地把所有 SELECT 都发给从库，是延迟问题的根源。实际要根据用户感知和业务影响做分级：
- 强一致读：支付扣款后查余额、订单创建后查状态、用户刚改完密码立刻登录——这类操作必须走主库，哪怕多一次连接开销
- 会话级一致读：用户修改资料后立即刷新个人页，可用 ThreadLocal 记录本次请求写过主库，后续同一线程内的读自动路由到主库（ShardingSphere 支持 hint 强制主库）
- 最终一致读：商品浏览、评论列表、热搜排行——允许秒级延迟，直接走从库，甚至可加缓存兜底
从源头压减延迟产生条件
延迟不是凭空出现的，多数来自主库“制造”，从库“消化不了”。重点盯住三类高危操作：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 拆大事务：避免单次更新 10 万行。改成 for 循环分批（每批 500~1000 行），配合 sleep(10ms) 或异步队列削峰
- DDL 操作避峰+灰度：千万级表加索引，用 pt-online-schema-change 工具，不锁主库，也不阻塞从库重放
- 从库资源隔离：禁止在从库跑报表导出、ETL 同步等长耗时任务；监控从库 CPU、IO Wait、Seconds_Behind_Master，超阈值自动告警并降权路由
应用层动态路由与兜底机制
靠静态配置“读=从库”太粗放。真实项目中需结合实时指标做智能调度：
- 延迟感知路由：定期执行 select master_pos_wait() 或查 Seconds_Behind_Master，若某从库延迟 > 500ms，临时剔除其读流量（ShardingSphere 支持自定义负载均衡算法）
- 写后强制主库读：用注解 @MasterRead 标记关键方法，AOP 拦截后切换数据源；或统一约定 URL 参数如 ?consistency=strong，网关层解析并透传
- 缓存兜底：写主库成功后，主动更新 Redis 中对应 key（如 user:1001），读请求先查缓存命中即返回，未命中再查从库——既缓解延迟影响，又降低 DB 压力
监控与可观测性不能少
没监控的优化等于蒙眼开车。至少要落地三项基础观测：
- 主从延迟基线：采集每个从库的 Seconds_Behind_Master，设置 P95 ≤ 200ms 的 SLO，超时触发企业微信/钉钉告警
- 路由链路追踪：在 MyBatis 拦截器里打点，记录每次 SQL 执行走的是 master 还是 slave，配合 SkyWalking 查看不一致读发生的具体接口
- 慢同步语句定位：开启从库 slow_query_log，过滤执行时间 > 1s 的 SQL，反向查主库 binlog 找出源头大事务或低效 update
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
