先看last_sql_error，执行show slave status\g定位错误码（如1062、1032、1418）；rbr模式下须用mysqlbinlog解析relay log确认真实sql；1062和1032优先手动修复数据而非跳过；跳过仅限sbr且单次偶发，严禁slave_skip_errors=all。
先看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常因从库残留了不该有的数据；1032往往说明主从某行已不一致；1418则和权限或binlog_format有关，跟数据一致性无关。
RBR模式下必须用mysqlbinlog解析relay log
MySQL 5.7+默认是RBR（基于行的复制），Last_SQL_Error通常只显示位置信息，例如at master log mysql-bin.000012, end_log_pos 123456，看不到真实SQL。这时必须用mysqlbinlog解析从库本地的relay log：
mysqlbinlog --base64-output=decode-rows -v \ --start-position=123400 --stop-position=123500 \ /var/lib/mysql/relay-log.000001 > err.sql
重点看输出里### UPDATE或### DELETE前后的表名、WHERE条件。注意：
- Docker环境下，relay log文件名可能带主机名前缀，先用
ls /var/lib/mysql/*relay*确认真实路径 - 如果解析出的语句在从库上手动执行也报错（如
Table 'xxx' doesn't exist），说明DDL没同步或顺序错乱 - 如果语句本身没问题，但从库查不到对应行，就得分别查主从两边该行是否存在——不能默认主库是对的
跳过错误前必须分清SBR还是RBR，且仅限单次偶发
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1是临时跳过当前事务的“止血针”，但有严格前提：
- 只对SBR（基于语句的复制）可靠；RBR下它可能跳过一个事务里的部分行变更，留下半截脏数据
- 仅适用于单次偶发错误，比如一条误删引发的
1032，且你确认主库该操作合理、从库缺失可接受 - 执行前必须
STOP SLAVE，执行后START SLAVE，否则无效 - 跳过后务必再查
Seconds_Behind_Master是否归零，并比对关键表数据
绝对禁止配置slave_skip_errors = all：它会掩盖主键冲突、外键失败、DDL执行失败等严重问题，等于主动关闭数据一致性监控。
1062和1032优先手动修复，不是跳过
这两类错误本质是主从数据不一致，跳过只是绕开症状。正确路径是：
- 对
1062（主键重复）：登录从库，SELECT * FROM table_name WHERE id = X确认冲突行是否存在；存在就DELETE掉，再START SLAVE - 对
1032（记录不存在）：先查主库binlog或业务日志，确认那行是否真被删了；若主库已删，从库补删即可；若主库没删，说明从库误删，需从备份恢复或回放缺失binlog
最容易被忽略的是：GTID模式下SQL_SLAVE_SKIP_COUNTER完全失效，必须用SET GTID_NEXT + 空事务方式跳过；而read_only=1只能防普通用户写，super权限用户仍可修改——真要锁死，得配合FLUSH TABLES WITH READ LOCK。
