检查 SHOW SLAVE STATUS
中关键字段是否异常
主从不同步的第一反应不是重启，而是看状态。执行
SHOW SLAVE STATUS\G后重点关注这几个字段：
Slave_IO_Running和
Slave_SQL_Running必须都是
Yes，任一为
No表示复制线程已停
Seconds_Behind_Master为
NULL通常意味着 SQL 线程没在运行（不是延迟大）
SQL_Delay非零说明人为设置了延迟复制，不是故障
Last_IO_Error或
Last_SQL_Error会直接告诉你卡在哪条语句、什么错误（比如主键冲突、表不存在）
常见 Last_SQL_Error
类型及修复方式
SQL 线程报错是最常见的同步中断原因，不同错误要区别对待：
主键/唯一键冲突（Duplicate entry 'xxx' for key 'PRIMARY'）：可能是从库被误写，或主库 binlog 格式为
STATEMENT时函数不安全。临时跳过可用
SET GLOBAL sql_slave_skip_counter = 1（仅限
ROW格式下谨慎使用），但更推荐先查清从库多出了什么数据，再人工清理或补主库缺失变更 表不存在（
Table 'db.t' doesn't exist）：主库执行了
DROP TABLE，但从库该表已被手动删过或未同步建表语句。检查主库 binlog 确认操作历史，必要时重放建表语句或重建从库 列数不匹配（
Column count doesn't match value count）：大概率是主从表结构不一致，用
DESCRIBE db.t逐字段比对，注意默认值、是否允许 NULL、字符集差异
确认主从 binlog 位置是否真的脱节
有时
Seconds_Behind_Master显示很大，但实际只是 IO 线程拉取慢，SQL 线程仍在追。需交叉验证： 在主库查
SHOW MASTER STATUS，记下
File和
Position在从库查
SHOW SLAVE STATUS，对比
Master_Log_File和
Read_Master_Log_Pos（IO 线程读到哪）以及
Relay_Master_Log_File和
Exec_Master_Log_Pos（SQL 线程执行到哪） 若
Read_Master_Log_Pos远落后于主库
Position，说明网络或主库写压力大导致 IO 拉取慢；若
Exec_Master_Log_Pos落后但
Read_Master_Log_Pos接近，则是 SQL 线程执行慢（如大事务、磁盘 I/O 差、从库负载高）
跳过错误或重置复制前必须确认的三件事
不要一看到
SQL_THREAD停就急着
START SLAVE或跳过错误： 确认主库 binlog 没被
PURGE过——如果从库还没读的 binlog 已被主库清理，强行跳过只会让数据永久不一致 确认从库没有被业务直连写入——任何在从库执行的
INSERT/UPDATE/DELETE都可能破坏复制逻辑 确认 GTID 模式是否开启（
gtid_mode = ON）——开启后不能用
sql_slave_skip_counter，必须用
SET GTID_NEXT='xxx'; BEGIN; COMMIT;注入空事务来跳过
真正难处理的是主从数据逻辑不一致但复制线程又没报错的情况，这时候光看状态没用，得靠工具如
pt-table-checksum对比行级数据。
