mysql主从复制出错时，GTID 关闭环境用 SET GLOBAL sql_slave_skip_counter= 1 跳过单事务；GTID 开启时需 SET GTID_NEXT+BEGIN+COMMIT 伪造已执行；批量跳过可重设同步点，但须确保主库 binlog 存在；预防优于跳过，应设 read_only、校验结构、监控状态。
MySQL 主从复制中遇到错误（比如主库执行了从库不存在的表或数据冲突），有时需要跳过特定事务继续同步。跳过事务不是常规操作，应先排查根本原因，但紧急恢复时可临时使用以下方法。
跳过一个事务（推荐用于 GTID 关闭环境）
适用于传统基于 binlog 位置的复制（gtid_mode=OFF）。需先停止从库复制，再跳过当前报错的 事件：
- 登录从库执行：STOP SLAVE;
- 查看当前复制状态：SHOW SLAVE STATUSG，记录 Relay_Master_Log_File 和 Exec_Master_Log_Pos
- 手动前进一个事件位置（通常 + 1 即可，但需确认是 statement 还是 row 格式；稳妥做法是 +4）：SET GLOBAL sql_slave_skip_counter = 1;
- 重新启动复制：START SLAVE;
⚠️ 注意：sql_slave_skip_counter 在 GTID 模式下不可用，启用 GTID 后必须用其他方式。
在 GTID 模式下跳过事务（主流推荐方式）
当 gtid_mode=ON 且启用了 enforce_gtid_consistency=ON 时，必须用 GTID 集合方式跳过：
- 停从库：STOP SLAVE;
- 从 SHOW SLAVE STATUSG 中找到 Retrieved_Gtid_Set 和 Executed_Gtid_Set，并确认报错事务的 GTID（如
3e11fa47-71ca-11e1-9e33-c80aa9429562:23） - 将该 GTID 加入从库的已执行集合（伪造已执行）：SET GTID_NEXT = ‘3e11fa47-71ca-11e1-9e33-c80aa9429562:23’; BEGIN; COMMIT; SET GTID_NEXT = ‘AUTOMATIC’;
- 重启复制：START SLAVE;
✅ 这种方式精准跳过单个事务，不影响 GTID 一致性，是 GTID 环境下的标准操作。
跳过多条事务或批量跳过（谨慎使用）
若连续多个事务出错（如批量导入引发冲突），可临时清空 relay log 并重设同步点，但需确保主库 binlog 未被清理：
- 停从库：STOP SLAVE;
- 在主库查当前位置：SHOW MASTER STATUS;
- 在从库执行：CHANGE MASTER TO MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=12345;（填主库实际文件和位置）
- START SLAVE;
⚠️ 此操作相当于“重置从库到主库某一点”，会丢弃该点之前所有未同步的 relay 日志，务必核对位置准确、主库 binlog 存在。
预防比跳过更重要
频繁跳过事务说明 架构 或操作流程存在隐患，建议：
- 从库设置 read_only=ON，避免误写
- 主从表结构严格一致，上线前校验 DDL
- 禁止在从库执行
INSERT/UPDATE/delete（除非业务明确允许） - 监控 Seconds_Behind_Master 和 Slave_SQL_Running_State，及时发现异常
- 关键业务开启 slave_exec_mode=IDEMPOTENT（仅限 MySQL 5.7+），部分冲突可自动忽略
不复杂但容易忽略。
