MySQL主从复制中遇到错误（比如主库执行了从库不存在的表或数据冲突），有时需要跳过特定事务继续同步。跳过事务不是常规操作，应先排查根本原因，但紧急恢复时可临时使用以下方法。
跳过一个事务（推荐用于GTID关闭环境）
适用于传统基于binlog位置的复制（gtid_mode=OFF）。需先停止从库复制，再跳过当前报错的事件：
登录从库执行：STOP SLAVE; 查看当前复制状态：SHOW SLAVE STATUS\G，记录 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 STATUS\G 中找到 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+），部分冲突可自动忽略
不复杂但容易忽略。
