MySQL开启GTID模式的主从复制架构中，从库执行事务时如果碰到错误，会导致同步线程停止，此时需要跳过出错的指定GTID事务来恢复同步。通过SET gtid_next配合注入空事务的方式，可以快速完成这个操作，不需要像传统模式那样计算binlog偏移量。
操作前的必要准备
在执行跳过操作之前，需要先确认几个关键信息，避免误操作导致数据不一致：
- 确认从库同步停止的原因，确保是需要跳过的GTID事务本身有问题，而不是其他环境故障
- 记录需要跳过的GTID值，可以通过从库的错误日志或者
SHOW SLAVE STATUSG命令获取 - 确保当前会话没有开启其他事务，避免干扰空事务的注入
具体操作步骤
1. 停止从库同步线程
首先停止从库的IO线程和SQL线程，避免新的事务进来影响操作：
-- 停止从库同步 STOP SLAVE;
2. 设置下一个GTID为需要跳过的事务
使用SET gtid_next命令，将下一个要执行的事务GTID设置为需要跳过的事务ID：
-- 替换为实际需要跳过的GTID值，格式为source_id:transaction_id SET gtid_next='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:12345';
3. 注入空事务
在设置完gtid_next之后，执行一个空事务，这个事务会被标记为指定的GTID，但是不会修改任何实际数据，相当于跳过了该事务：
-- 注入空事务 BEGIN; COMMIT;
4. 恢复gtid_next为自动模式
空事务执行完成后，需要将gtid_next改回自动模式，让后续事务正常生成或获取GTID：
-- 恢复自动分配GTID SET gtid_next='AUTOMATIC';
5. 启动从库同步
重新启动从库的同步线程，检查同步是否恢复正常：
-- 启动从库同步 START SLAVE;
操作验证
操作完成后，需要验证跳过是否生效：
- 执行
SHOW SLAVE STATUSG命令，查看Slave_IO_Running和Slave_SQL_Running是否都为YES - 查看Retrieved_Gtid_Set和Executed_Gtid_Set，确认需要跳过的GTID已经包含在Executed_Gtid_Set中
- 检查从库数据是否和主库保持一致，确认没有因为跳过事务导致数据缺失
注意事项
跳过GTID事务属于风险操作，需要谨慎使用：
- 如果跳过的事务是修改数据的操作，可能会导致主从数据不一致，需要后续手动补全数据
- 不要随意跳过多个GTID事务，尽量只跳过确认有问题的单个事务
- 操作前最好对从库做一次数据备份，避免操作失误无法回滚
注意：如果主从复制使用的是多源复制，需要在STOP SLAVE和START SLAVE时指定对应的复制通道，避免影响其他通道的同步。
常见问题说明
为什么不能用传统的方式跳过事务？
传统模式通过SET GLOBAL sql_slave_skip_counter=1跳过事务，但是在GTID模式下，该参数已经失效，必须使用SET gtid_next的方式，否则会报错。
注入空事务会影响主库的GTID吗？
不会，gtid_next的设置只对当前会话有效，注入的空事务只会记录在从库自己的GTID执行集合中，不会同步回主库，也不会影响主库的GTID生成。