必须先确认错误类型、gtid状态和数据一致性才能跳过：查看show slave status\g中的last_sql_error（如1062可评估，1054须修结构）、slave_sql_running是否为no、retrieved_gtid_set与executed_gtid_set差值；gtid模式下用set gtid_next+begin/commit精准跳过，非gtid模式需手动定位relay_log_pos；禁用sql_slave_skip_counter，跳后必须验证数据一致性。
直接跳过主从复制错误事务不安全，必须先确认错误类型、GTID状态和数据一致性。盲目执行 SET GLOBAL sql_slave_skip_counter = 1 或空事务，大概率导致主从数据永久错位。
怎么判断该不该跳、能不能跳
登录从库执行 SHOW SLAVE STATUS\G，重点看三项：
-
Last_SQL_Error：比如ERROR 1062 (HY000): Duplicate entry '1' for key 'PRIMARY'属于可评估跳过的典型；但ERROR 1054 (HY000): Unknown column 'xxx' in 'field list'说明表结构不一致，必须先修复结构，不能跳 -
Slave_SQL_Running和Seconds_Behind_Master：若为No且NULL，说明 SQL 线程已停，需人工介入 -
Retrieved_Gtid_Set与Executed_Gtid_Set是否有差值：有差值且gtid_mode = ON，说明是 GTID 模式，sql_slave_skip_counter会直接报错，必须走 GTID 跳过路径
GTID 模式下跳过单个事务（推荐方式）
这是当前主流部署的首选方法，精准、可审计、不破坏 GTID 集合连续性。
- 从
Last_SQL_Error或Relay_Master_Log_File+Exec_Master_Log_Pos对应的 binlog event 中提取出错事务的完整 GTID，例如e46c9961-5780-11ea-bf2f-000c128a8b6b:12345——注意大小写、冒号、分号一个都不能错 - 执行顺序不可颠倒：
STOP SLAVE;→SET GTID_NEXT = 'e46c9961-5780-11ea-bf2f-000c128a8b6b:12345';→BEGIN; COMMIT;→SET GTID_NEXT = 'AUTOMATIC';→START SLAVE; - 跳过之后立刻查
Exec_Master_Log_Pos是否推进、Seconds_Behind_Master是否开始下降；再在主库插一条带时间戳的测试记录，去从库验证是否同步成功
非 GTID 模式下用 relay_log_pos 跳过（仅限紧急兜底）
该方式依赖手动定位，风险高，容易跳到事务中间或跳过不该跳的事件，仅用于 gtid_mode = OFF 且无法切 GTID 的旧环境。
- 停复制：
STOP SLAVE; - 记下
Relay_Master_Log_File（如mysql-bin.000061）和Exec_Master_Log_Pos（如1766），这个位置是出错事务在主库 binlog 中的结束点 - 用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000061 | grep -A 10 "at 1766"查看该位置附近语句，确认下一条事务确实从1767开始（ROW 格式通常 +1 即可，STATEMENT 格式可能需 +4 或更多） - 执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000061', MASTER_LOG_POS=1767;，再START SLAVE;
为什么 sql_slave_skip_counter 经常失效或危险
它不是“跳过报错那条”，而是“跳过下一条事件”，且只对 STATEMENT 格式 + 非 GTID 环境有效。
- 在 GTID 模式下执行会直接报错：
ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON - 即使在非 GTID 环境，InnoDB 事务包含多语句时，它跳过的可能是事务内第二条 UPDATE，而第一条 INSERT 已执行，造成部分写入
- 启用多线程复制（
slave_parallel_workers > 0）时行为不可靠，跳过位置可能错乱 - 跳完不检查
Exec_Master_Log_Pos是否推进，就以为恢复了——其实 SQL 线程可能卡在下一个事务
真正关键的不是“怎么跳”，而是“跳完之后有没有验证数据一致性”。跳过只是让复制跑起来，不代表数据正确；尤其主键冲突类错误，往往意味着从库已有脏数据，跳过只是掩盖问题。生产环境建议优先设 read_only = ON、统一 sql_mode、禁用从库手动写入，把精力放在预防上。
