MySQL主从复制延迟本质是从库 SQL 线程追不上主库写入节奏，核心矛盾在于“主库可并发写，从库只能串行回放”。排查要分两步走：先确认是否真延迟，再定位卡点在哪一环。
怎么看是不是真延迟？
登录从库执行：
SHOW SLAVE STATUS\G
重点关注三项：
哪些情况会导致延迟持续增大？
常见原因按发生频率和影响程度排序：
大事务回放慢：主库一个 DELETE/UPDATE 涉及百万行，从库 SQL 线程需逐行执行（尤其 RBR 模式），期间无法处理后续事件 从库单线程瓶颈：MySQL 5.6 默认 SQL 线程单线程，高并发写入下必然积压；即使 IO 线程已拉完 relay log，SQL 线程仍排队 从库硬件或负载过高：磁盘慢（如机械盘跑 relay log 写入）、CPU 满载、内存不足触发 swap，或从库同时跑报表、备份等重负载 无主键或缺失索引的表更新：UPDATE/DELETE 语句无法高效定位行，全表扫描拖慢回放速度 网络传输慢：主从间带宽不足或丢包，IO 线程拉 binlog 不及时，Relay_Log_Space 持续增长怎么快速定位卡在哪一步？
用组合命令缩小范围：
查主库最新位置：SHOW MASTER STATUS → 记下 File 和 Position 查从库同步进度：SHOW SLAVE STATUS\G → 对比 Master_Log_File / Read_Master_Log_Pos（IO 是否拉到最新）和 Exec_Master_Log_Pos（SQL 是否执行到最新） 若 Read_Master_Log_Pos ≈ 主库 Position，但 Exec_Master_Log_Pos 落后很多 → 卡在 SQL 回放，重点看慢查询、锁、大事务 若 Read_Master_Log_Pos 远落后主库 Position → 卡在 IO 传输，检查网络、主库 binlog 写压力、从库磁盘 I/O 用 SHOW PROCESSLIST 查看从库 SQL 线程状态：若长期显示 Updating 或 Deleting，大概率正在回放大事务临时缓解和长期优化方向
不建议直接跳过错误或重搭从库，优先尝试可控手段：
开启并行复制：5.7+ 推荐设 slave_parallel_type = 'LOGICAL_CLOCK' + slave_parallel_workers = 4~8（根据 CPU 核数） 拆分大事务：业务侧将单次百万级更新改为每 5000 行 commit 一次；DBA 可用 pt-archiver 工具安全归档 加固从库基础：确保 relay log 和数据目录在 SSD 上；关闭从库不必要的功能（如 query cache）；专用服务器，避免混部 加监控告警：对 Seconds_Behind_Master > 30s 持续 2 分钟以上触发告警；配合 pt-heartbeat 表做更精准延迟检测
