原因
主库执行写操作后，会将变更记录写入 binlog。从库通过 IO 线程从主库拉取 binlog，再由 SQL 线程将其重放到本地。MySQL 5.7 之前从库的 SQL 线程是单线程串行回放，而主库是多线程并发写入，两者速度不匹配就会产生延迟。此外，网络抖动、从库机器性能不足、大事务、DDL 操作等也会加剧延迟。
处理方式
开启并行复制（推荐） ：MySQL 5.7 引入了基于逻辑时钟的并行复制（slave_parallel_type = LOGICAL_CLOCK），允许从库多线程并行回放 binlog，大幅缩短延迟。MySQL 8.0 进一步优化了并行度，是目前最推荐的方案。
强制走主库：对一致性要求极高的读操作（如支付后立即查询订单）直接路由到主库，牺牲一定的主库压力换取强一致性。需要配合读写分离中间件（如 ShardingSphere）按业务场景精细控制，避免全量读流量打到主库。
缓存兜底：写操作完成后，将最新数据同步写入 Redis 并设置短暂过期时间（如 3~5 秒）。读请求优先查 Redis，命中则直接返回，避免读到从库的旧数据；缓存过期后从库延迟通常也已追上，再走正常的读从库逻辑。你描述的"读主库"逻辑可以进一步简化------直接读缓存即可，不必再回源主库。
半同步复制：主库在提交事务时，至少等待一个从库确认已接收 binlog 后才返回成功，从源头上减少数据丢失窗口，但会略微增加主库写入延迟，适合对数据安全性要求高的场景。
一句话总结核心原因：
主库并发写 → binlog → 从库单线程串行回放，速度跟不上，产生延迟。
- 数据，设置过期时间，当读取该数据时，若是最近变更的数据，则读主库，否则读从库。