主从延迟本质是从库sql线程重放速度跟不上主库写入节奏，核心瓶颈包括单线程回放、大事务拖累及硬件网络失衡；需结合并行复制（logical_clock+workers）、应用层强一致读路由、拆分大事务及半同步机制系统性解决。
主从延迟和数据一致性不是两个孤立问题，而是同一链条上的不同阶段表现：延迟是过程态，不一致是结果态。解决的关键在于让从库“追得上”且“跟得准”。
看清延迟根源：三类典型瓶颈
延迟本质是从库SQL线程重放速度跟不上主库写入节奏。常见卡点集中在：
- 单线程瓶颈：MySQL 5.6以前仅靠一个SQL线程串行回放，主库并发高时必然积压；
- 大事务拖累：一个更新10万行的UPDATE语句，在主库可能几秒完成，但从库SQL线程需逐行执行，持续阻塞后续所有事件；
- 硬件与网络失衡：从库磁盘I/O慢（如用机械盘）、CPU核数不足、跨机房带宽小（实测低于20MB/s易成瓶颈），都会放大延迟。
并行复制必须配对启用
只开slave_parallel_workers没用，关键要激活并行调度逻辑：
- MySQL 5.7+ 推荐设slave_parallel_type = LOGICAL_CLOCK，它依据主库事务提交组（commit group）划分并行单元，比按库名分更适配现代单库多表架构；
- 配套设置slave_parallel_workers = 4~8（建议从4起步，观察CPU使用率再调）；
- 确保主库开启binlog_transaction_dependency_tracking = WRITESET（MySQL 8.0+），提升事务依赖识别精度，减少误串行。
从应用层规避读写不一致
不能全指望数据库自动同步到位，业务需主动兜底：
- 强一致性读走主库：用户刚下单、支付成功后立即查订单状态，这类“写后即读”请求应通过路由规则强制发往主库；
- 延迟感知+降级策略：在读从库前先查SHOW SLAVE STATUS\G中的Seconds_Behind_Master，若>3秒，可返回缓存旧数据或提示“数据刷新中”；
- 拆分大事务：将批量导入、统计更新等操作拆为每千行一批，加短暂停顿，避免单事务垄断SQL线程。
半同步复制守住底线
异步复制下，主库崩溃瞬间未同步到从库的数据就永久丢失。启用半同步能保证至少一个从库落盘才返回成功：
- 主库配置：rpl_semi_sync_master_enabled = 1，超时设为rpl_semi_sync_master_timeout = 10000（10秒，超时自动降级为异步，避免阻塞业务）；
- 从库配置：rpl_semi_sync_slave_enabled = 1；
- 注意：半同步不解决延迟，但能防止“主挂了，从库数据更旧”的灾难场景。
