必须先执行show variables like 'gtid_mode'确认模式，若为on则属gtid模式，此时sql_slave_skip_counter已弃用，须用stop replica→set gtid_next→begin;commit→set gtid_next='automatic'→start replica五步注入空事务跳过1062错误。
MySQL 8.0 中跳过复制错误不能靠“试一试”，必须先确认 GTID 模式是否启用，否则 sql_slave_skip_counter 会直接报错或被忽略——这是绝大多数人卡住的第一步。
先查 gtid_mode，别凭经验猜
执行 SHOW VARIABLES LIKE 'gtid_mode';，返回 ON 就是 GTID 模式；返回 OFF 才能用传统跳过方式。常见误判包括：看到 Executed_Gtid_Set 非空就以为开了 GTID（可能是旧从库残留），或主库开了但从库没开（复制会卡在 1062 且无法跳过）。MySQL 8.0.23+ 默认倾向启用 GTID，sql_slave_skip_counter 已标记为 deprecated，8.0.26 起正式由 sql_replica_skip_counter 替代。
GTID 模式下跳过 1062 错误：五步缺一不可
跳过本质是“伪造已执行”，靠注入空事务消耗掉冲突事务的 GTID。漏一步或抄错一位字符，GTID 集合就永久错乱，只能重建从库。
- STOP REPLICA;（MySQL 8.0.22+ 推荐用 REPLICA，SLAVE 已弃用）
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，形如3e11fa47-71ca-11e1-9e33-c80aa9429562:23，冒号前后不能有空格，大小写必须完全一致 SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';-
BEGIN; COMMIT;（必须是空事务，不能带任何 DML） SET GTID_NEXT = 'AUTOMATIC'; START REPLICA;
注意：BEGIN; COMMIT; 若在 COMMIT 前连接断开，GTID 不会加入 Executed_Gtid_Set，后续仍报错。
非 GTID 模式下跳过：限制条件比想象中多
SET GLOBAL sql_replica_skip_counter = 1 看似简单，但生效前提苛刻：
- 必须先停 SQL 线程：
STOP REPLICA SQL_THREAD;（不是STOP REPLICA;，后者会同时停 IO 线程） - 要求
relay_log_recovery = OFF，否则跳过无效 - 仅对
binlog_format = STATEMENT有效；如果是 ROW 格式，该命令不起作用 - 若启用了多线程复制（
slave_parallel_workers > 0），行为不可靠，建议先设为 0 再操作
跳过之后，Exec_Master_Log_Pos 会前进，但 Executed_Gtid_Set 不变（因为没开 GTID），这点和 GTID 模式不同。
RDS 环境优先用 mysql.rds_skip_repl_error
Amazon RDS for MySQL 提供了封装好的存储过程，比手动操作更安全：
- 连接只读副本后直接执行：
CALL mysql.rds_skip_repl_error; - 若报错
ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist，说明实例版本过低，需升级到支持该过程的最小次要版本 - 不推荐长期设置
slave_skip_errors参数（如1062,1053），它属于静态参数，修改后需重启实例，且可能掩盖真实问题
真正麻烦的从来不是那条报错语句本身，而是跳过之后发现 auto-increment 偏移错位、唯一索引残留脏数据、或 binlog_format 不一致导致后续事件解析失败——这些不会立刻报错，但会在几天后引发更隐蔽的同步断裂。
