Seconds_Behind_Master突增数小时，非单纯变慢而是同步链路实质卡死；须先查Slave_IO_Running和Slave_SQL_Running状态及Last_IO/SQL_Errno，再结合GTID或位点判断是否可跳过或需重建从库。
Seconds_Behind_Master 突然飙到几小时，先别重启从库
这种延迟不是“慢”，而是同步链路已实质卡死。直接 START SLAVE 很可能让从库陷入无限重试或复制中断状态，尤其当 relay log 已损坏、主库 binlog 被清理、或 SQL 线程报错被忽略时。SHOW SLAVE STATUS\G 里重点盯三个字段：Seconds_Behind_Master（假高值常见于网络断连）、Slave_IO_Running（是否还在收日志）、Slave_SQL_Running（是否还在执行）。如果其中任一为 No，必须先定位错误号，比如 Last_IO_Errno 或 Last_SQL_Errno。
快速跳过不可恢复的事务（慎用）
当确认是单点 SQL 执行失败（如从库缺失表、唯一键冲突、函数不存在），且业务允许丢弃这部分数据时，可临时跳过。但注意：MySQL 5.7+ 不再支持 SET GLOBAL sql_slave_skip_counter=1（仅对 STATEMENT 格式有效），必须用 GTID 方式：
- 查当前从库已执行的 GTID 集合：
SELECT @@global.gtid_executed; - 查主库对应位置的 GTID（需提前记录或通过
mysqlbinlog解析主库 binlog） - 手动设置跳过：
STOP SLAVE; SET GTID_NEXT='xxx-xxx-xxx:nnn'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE; - 跳过后立刻检查
Exec_Master_Log_Pos是否前进，避免“假启动”
跳过操作不可逆，务必在跳之前备份从库数据或至少导出关键表。
重建从库比硬追更快
延迟超 30 分钟，尤其达到数小时，往往意味着 relay log 积压严重、磁盘 IO 持续满载、SQL 线程频繁锁等待。此时强行追日志，耗时可能远超重新拉取——特别是主库启用了 expire_logs_days，旧 binlog 已被清理，从库根本无法补全。
- 停掉问题从库：
STOP SLAVE; - 用
mysqldump --single-transaction --master-data=2或Percona XtraBackup对主库做一致性快照 - 在新实例上恢复，并确保
CHANGE MASTER TO指向正确的 binlog 文件和 position（或 GTID） - 优先考虑用
XtraBackup：它不锁表、速度快、支持流式传输，适合大库
重建过程本身可控，而“硬追”完全不可控——你不知道下一个阻塞点在哪，也不知道要等多久。
延迟归零后，立刻关掉并行复制的“假开关”
很多团队开了 slave_parallel_workers 就以为万事大吉，但没配 slave_parallel_type=LOGICAL_CLOCK 或 MySQL 版本低于 5.7，实际仍是单线程。更隐蔽的是：MySQL 8.0 默认启用 WRITESET 并行，但若主库未开启 binlog_transaction_dependency_tracking=WRITESET，从库会自动降级回 LOGICAL_CLOCK 模式，而该模式依赖主库的 commit 时间戳——一旦主库系统时间被校准或 NTP 同步抖动，就可能导致并行组划分异常，SQL 线程排队等待，延迟悄悄回升。
- 确认主库已设：
SET GLOBAL binlog_transaction_dependency_tracking=WRITESET; - 确认从库已设：
SET GLOBAL slave_parallel_type='LOGICAL_CLOCK';（5.7）或'WRITESET'（8.0） - 检查
SHOW PROCESSLIST中是否有大量Waiting for dependent transaction to commit
真正起效的并行复制，不是开了几个 worker 线程，而是主库写入时就已按行级依赖打标——这点最容易被忽略，也最影响长期稳定性。
