先看last_sql_error，别急着start slave；看到slave_sql_running: no，第一件事是执行show slave status\g，紧盯last_sql_error字段确认错误码（如1062、1032、1418等）及上下文，再结合mysqlbinlog解析relay log定位真实sql，区分错误类型后精准修复，严禁盲目跳过。
先看 Last_SQL_Error，别急着 START SLAVE
看到 Slave_SQL_Running: No，第一反应不是重启复制，而是立刻执行 SHOW SLAVE STATUS\G，盯住 Last_SQL_Error 字段。它直接告诉你 SQL 线程卡在哪条语句、什么错误码——比如 Error_code: 1062（主键重复）、Error_code: 1032（找不到记录）、Error_code: 1418（函数不安全）等。这些错误成因完全不同，混用修复方式反而扩大不一致。
区分错误类型再动手
不同错误码对应完全不同的处理逻辑，不能一概跳过：
-
1062：多半是主库插入重复主键，但更常见的是从库残留了不该有的数据（比如手动INSERT过），优先删掉从库冲突行，而不是跳过 -
1032：表示从库执行UPDATE/DELETE时找不到目标行，可能主库删了、从库没删；也可能是表没主键或唯一索引，导致 RBR 模式下定位失败 -
1418或1236：通常指向binlog_format配置、函数定义（如未加DETERMINISTIC）或权限问题，和数据一致性无关，要单独改配置或重定义函数 -
1007（数据库已存在）或1050（表已存在）：说明 DDL 在从库重复执行，常见于未关闭sql_log_bin时在从库手动建库建表
RBR 模式下必须解析 relay log
在 binlog_format = ROW 模式下，Last_SQL_Error 往往只显示位置（如 at master log mysql-bin.000012, end_log_pos 123456），看不到具体哪条语句出错。这时候必须用 mysqlbinlog 解析 relay log 才能确认真实 SQL：
- 先从
SHOW SLAVE STATUS\G中拿到Relay_Log_File和Relay_Log_Pos - 用命令
mysqlbinlog --base64-output=decode-rows -v /path/to/relay-log-file | grep -A 10 -B 10 "end_log_pos 123456"定位出错事件 - 重点看
### UPDATE ...或### DELETE FROM ...块，确认操作的表、条件字段和值
跳过错误前必须确认后果
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 或 slave_skip_errors = 1062 只是让 SQL 线程继续跑，不代表数据一致。尤其注意：
- 严禁设
slave_skip_errors = all，这等于放弃一致性校验 - GTID 模式下不能用
SQL_SLAVE_SKIP_COUNTER，必须用SET GTID_NEXT = 'xxx'; BEGIN; COMMIT;跳过单个事务 - 跳过之后，务必用
pt-table-checksum校验主从数据差异，再用pt-table-sync修复 - 如果错误反复出现（比如持续报
1032），说明主从某张表已长期不一致，该重建从库或全量同步
最常被忽略的一点：很多 Last_SQL_Error 表面是数据问题，根因却是配置漂移——比如从库开了 read_only = OFF 后被人误写，或者 server_id 与其他节点重复。查完错误码，顺手检查 show variables like 'read_only' 和 show variables like 'server_id' 是低成本高回报的动作。
