MySQL 主从复制延迟本质是从库 SQL 线程串行回放追不上主库并发写入节奏；需先通过 SHOW SLAVE STATUS 检查 Seconds_Behind_Master、IO/SQL 线程状态及日志位置差确认真实延迟，再依大事务、单线程瓶颈、硬件负载、缺失索引、网络问题等分层定位卡点。
MySQL 主从复制延迟本质是 从库 SQL 线程追不上主库写入节奏，核心矛盾在于“主库可并发写，从库只能串行回放”。排查要分两步走：先确认是否真延迟，再定位卡点在哪一环。
怎么看是不是真延迟？
登录从库执行：
SHOW SLAVE STATUSG
重点关注三项：
- Seconds_Behind_Master：非 NULL 且持续增长，说明有真实延迟；若为 0 或忽高忽低，可能是瞬时抖动或时间不同步（主从系统时间差 1 秒，SBM 就差 1 秒）
- Slave_IO_Running 和 Slave_SQL_Running 都必须为 Yes；任一为 No，说明复制已中断，不是“延迟”，而是“断连”
- 对比 Read_Master_Log_Pos 和 Exec_Master_Log_Pos：差值越大，中继日志积压越严重，SQL 线程明显跟不上
哪些情况会导致延迟持续增大？
常见原因按发生频率和影响程度排序：
- 大事务回放慢：主库一个 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 STATUSG → 对比 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 表做更精准延迟检测
