查last_sql_error定位错误码看到slave_sql_running: no，第一件事是执行show slave status\g查看last_sql_error字段，明确错误码（如1062、1032、1418）及上下文；再结合mysqlbinlog解析relay log确认真实sql，区分跳过或手动修复。
查Last_SQL_Error定位错误码
看到 Slave_SQL_Running: No，第一件事不是重启或跳过，而是执行 SHOW SLAVE STATUS\G，直接看 Last_SQL_Error 字段。它会明确告诉你卡在哪条语句、什么错误码——比如 Error_code: 1062（主键冲突）、Error_code: 1032（找不到记录）、Error_code: 1418（函数创建不安全）等。这些错误背后原因完全不同，混用修复方式反而扩大不一致。
- 1062 多半是主库插入重复主键，但更常见的是从库残留了不该有的数据（比如手动 INSERT 过）
- 1032 表示从库执行 UPDATE/DELETE 时找不到目标行，可能主库删了、从库没删，也可能表根本没主键
- 1418 或 1236 通常指向 binlog 格式、函数定义或权限问题，和数据一致性无关，要单独处理
解析 relay log 确认真实 SQL
RBR（行复制）模式下，Last_SQL_Error 往往只显示位置（如 at master log mysql-bin.000012, end_log_pos 123456），看不到具体哪条语句出错。必须用 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 条件。别只信报错信息，实际执行的可能是被改写过的语句。
- 如果解析出的语句在从库上手动执行也报错（比如
Table 'xxx' doesn't exist），说明 DDL 没同步或顺序错乱 - 如果语句本身没问题，但在从库找不到对应行，就要比对主从两边该行是否存在——不能默认主库是对的
- Docker 环境下注意路径：relay log 文件名可能带 host 名前缀，用
ls /var/lib/mysql/*relay*确认真实文件名
跳过还是修复？看错误类型和业务容忍度
跳过错误只是让 SQL 线程跑起来，不等于数据恢复一致。盲目用 SET GLOBAL sql_slave_skip_counter = 1 在 RBR 下风险很高——它可能跳过一个事务里的部分行变更，留下半截脏数据。
- 对 1062：先
SELECT * FROM table WHERE id = X查从库是否有冲突行；有则DELETE掉，再START SLAVE - 对 1032：查主库 binlog 或业务日志，确认那行是否真被删了；若主库已删，从库补删即可；若主库没删，说明从库误删，得从备份恢复或回放缺失 binlog
- GTID 模式下禁用
sql_slave_skip_counter，必须用SET GTID_NEXT = 'xxx:yyy'; BEGIN; COMMIT;注入空事务，且xxx:yyy必须严格匹配Retrieved_Gtid_Set和Executed_Gtid_Set的差集
为什么 STOP/START SLAVE 总是无效？
因为 START SLAVE 不会自动移动执行位点，SQL 线程仍会从上次失败的位置重试，陷入死循环。真正起作用的是调整起点：
- 用
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy手动指定下一个合法 binlog 位置（需提前在主库查SHOW MASTER STATUS或SHOW BINLOG EVENTS IN 'xxx' FROM yyy LIMIT 1） - 或者用
SET GLOBAL sql_slave_skip_counter = 1（仅限 SBR）后立刻START SLAVE，否则变量失效 - 如果 relay log 已损坏（比如磁盘满导致写入中断），
RESET SLAVE并重新配置是唯一办法，但会丢掉未执行的 relay event
最易被忽略的一点：很多 1032 报错根源不在 SQL 本身，而在表没有主键。并行复制一开，InnoDB 隐式 row_id 主从不一致，定位必然失败。加显式主键才是根治手段，跳过只是打补丁。
