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 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 线程仍在追。需交叉验证：
