SHOW SLAVE STATUS异常排查应先查Slave_IO_Running、Slave_sql_Running是否为Yes，Seconds_Behind_Master是否为NULL，Last_IO_Error/Last_SQL_Error具体报错，再结合主从binlog位置、表结构、GTID模式等综合判断。
检查 SHOW SLAVE STATUS 中关键字段是否异常
主从不同步的第一反应不是重启，而是看状态。执行 SHOW SLAVE STATUSG 后重点关注这几个字段：
-
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 对比行级数据。