必须先看Last_SQL_Error定位SQL线程失败语句，错误码（如1032、1062）是修复入口；Slave_IO_Running和Slave_SQL_Running需分开诊断，I/O线程异常查网络/权限/server_uuid，SQL线程异常则聚焦数据一致性风险。
直接看 Last_SQL_Error，它比任何经验都准——错误码（如 1032、1062）就是修复入口，跳过前不解析等于蒙眼修车。
查错必须先看 Last_SQL_Error 而不是急着 START SLAVE
当 SHOW SLAVE STATUS\G 显示 Slave_SQL_Running: No，第一反应不是重启或跳过，而是立刻定位 SQL 线程卡在哪条语句。关键字段是：
-
Last_IO_Errno和Last_IO_Error：I/O 线程问题（比如网络断开、权限不对、auto.cnf中server_uuid冲突） -
Last_SQL_Errno和Last_SQL_Error：SQL 线程执行失败，这才是数据一致性的真正风险点
常见错误码含义：
-
1032：Can't find record in 'xxx' —— 主库删/改了某行，从库已不存在该记录（典型数据漂移） -
1062：Duplicate entry 'xxx' for key 'PRIMARY' —— 主库插入了一条从库已存在的主键记录 -
1205：Deadlock found when trying to get lock —— 行锁冲突，多见于高并发写入场景 -
1213：Lock wait timeout exceeded —— 锁等待超时，常因长事务或未提交事务阻塞
注意：Last_SQL_Error 在 RBR（默认）模式下通常不显示具体 SQL，只提示事务 ID 和 binlog 位置，这时必须靠 mysqlbinlog 解析。
跳过错误不能无脑用 SQL_SLAVE_SKIP_COUNTER=1
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 是临时跳过当前事务的“止血针”，但有严格前提：
- 仅对 SBR（基于语句的复制）可靠；MySQL 5.7+ 默认是 RBR（基于行），跳过可能跳掉部分变更，导致后续主从不一致
- 只适用于单次偶发错误，比如一条误删引发的
1032，且确认主库该操作合理、从库缺失可接受 - 执行前必须
STOP SLAVE，执行后START SLAVE，否则无效 - 跳过后务必再查
Seconds_Behind_Master是否归零，并比对关键表数据
绝对禁止配置 slave_skip_errors = all：它会掩盖主键冲突、外键约束失败、DDL 执行失败等严重问题，生产环境等于自废监控。
遇到 1032 或 1062 应优先手动修复而非跳过
这两类错误本质是主从数据不一致，跳过只是绕开症状，不解决病根。正确路径是：
- 对
1062（主键重复）：登录从库，DELETE FROM table_name WHERE id = X;删除冲突行，再START SLAVE - 对
1032（记录不存在）：先确认主库是否真删了该行（查 binlog 或业务日志），若属实，从库无需补数据，直接跳过；若主库没删，说明从库误删，需从备份恢复或用mysqlbinlog回放缺失变更 - RBR 下定位不到具体语句？用
mysqlbinlog --base64-output=decode-rows -v --start-position=A --stop-position=B /var/lib/mysql/mysql-bin.0000xx解析出错事务的原始变更
特别注意：所有手动 DML 操作（如 DELETE）在从库执行前，必须确保 sql_log_bin = 0，否则会写入自身 binlog，造成环形复制或二次冲突。
Slave_IO_Running: No 和 Slave_SQL_Running: No 必须分开诊断
这两个线程职责不同，故障原因几乎不重叠：
-
Slave_IO_Running: No→ I/O 线程无法连接主库或读取 binlog，重点查：auto.cnf中server_uuid是否与主库重复（克隆虚拟机常见）、主库防火墙/端口、复制账号权限、MASTER_HOST是否可解析（建议配skip-name-resolve） -
Slave_SQL_Running: No→ 已成功拉取中继日志，但执行失败，核心就是Last_SQL_Error和对应错误码
一个容易被忽略的细节：如果从库曾被手动写入（哪怕只是一条 INSERT），就可能破坏 GTID 一致性或导致 position 偏移，此时 CHANGE MASTER TO 强制指定位点反而更稳妥，但要承担丢数据风险。
