主从延迟超30分钟且seconds_behind_master为null或持续极大值时，表明sql线程卡死而非缓慢；需检查slave_sql_running_state及gtid集合差异，若relay log损坏、主库binlog被purge、ddl不一致或延迟超24小时且sql线程长期阻塞，则应放弃修复、全量重建从库。
主从延迟超过 30 分钟，Seconds_Behind_Master 持续为 NULL 或极大值怎么办
直接看 SHOW SLAVE STATUS\G，重点盯 Seconds_Behind_Master、Slave_SQL_Running_State 和 Retrieved_Gtid_Set/Executed_Gtid_Set（如果启用了 GTID）。若 Seconds_Behind_Master 为 NULL，说明 SQL 线程已停止，不是“慢”，而是“卡死”；若数值持续上涨（比如 > 1800），基本可判定同步链路不可自愈。
别急着 kill 或 restart，先确认是否是临时性阻塞：
-
Slave_SQL_Running_State显示Waiting for dependent transaction to commit→ 可能是并行复制冲突，检查slave_preserve_commit_order=ON下的事务依赖 - 显示
Reading event from the relay log但无进展 → relay log 可能损坏，用mysqlbinlog手动解析对应Relay_Log_File+Relay_Log_Pos附近事件 -
Retrieved_Gtid_Set和Executed_Gtid_Set差距巨大且不再增长 → I/O 线程异常，检查主库max_allowed_packet是否被从库超限截断
什么情况下必须放弃增量恢复，直接全量重建从库
不是所有延迟都值得抢救。以下情况建议跳过修复，直接初始化：
- 从库
relay_log文件丢失或破损，且relay_log_purge=OFF未开启，无法定位中断点 - 主库 binlog 已被 purge，
Relay_Master_Log_File对应的文件在主库上不存在（查SHOW BINARY LOGS） - 从库出现
duplicate entry、no such table等 DDL/DML 不一致错误，且sql_slave_skip_counter已禁用（GTID 模式下不可用） - 延迟持续 > 24 小时，且
SHOW PROCESSLIST中 SQL 线程长期处于Updating或Copying to tmp table—— 很可能是大事务回放卡住，强行等不如重来
mysqldump 全量导出时必须加的 5 个参数
不加这些，导出的 SQL 很可能在从库上执行失败，或导致 GTID 不一致：
-
--single-transaction：确保一致性快照，但仅对 InnoDB 有效；若库中混有 MyISAM 表，必须搭配--lock-all-tables -
--master-data=2：写入CHANGE MASTER TO所需的 binlog 位置（非 GTID 模式）；若用 GTID，改用--set-gtid-purged=ON -
--routines和--triggers：存储过程和触发器默认不导出，漏掉会导致从库逻辑缺失 -
--hex-blob：避免 BLOB 字段中的二进制内容被终端乱码截断（尤其跨平台传输时）
示例命令：
mysqldump --single-transaction --master-data=2 --routines --triggers --hex-blob -u root -p mydb > mydb.sql
重建后校验从库数据是否真正一致
别只看 Seconds_Behind_Master = 0 就以为完事。GTID 模式下 Executed_Gtid_Set 相同也不代表数据一致 —— 比如某条 UPDATE 被误 skip 过，GTID 仍会推进。
- 用
pt-table-checksum（Percona Toolkit）做行级校验：它通过分块 CRC 校验，比SELECT COUNT(*)可靠得多，且支持在线不锁表 - 手动抽样对比：对核心表执行
SELECT MD5(CONCAT_WS('|', col1, col2, ...)) FROM t ORDER BY pk LIMIT 1000，在主从分别运行，比对结果集哈希 - 检查自增主键、时间戳字段是否连续合理：比如从库
id最大值明显小于主库，或created_at出现未来时间，说明部分写入丢失
最常被忽略的是：重建后没重置监控告警阈值，导致延迟归零后仍持续报警；或者忘了把从库 read_only 关闭再打开（SET GLOBAL read_only=ON），导致应用误写入。
