MySQL 5.7默认启用GTID，跳过事务必须用SET GTID_NEXT+空事务方式；先确认gtid_mode和enforce_gtid_consistency均为ON，再从Last_SQL_Error中精确提取GTID字符串执行STOP SLAVE、SET GTID_NEXT、BEGIN;COMMIT、SET GTID_NEXT=AUTOMATIC、START SLAVE，最后验证同步状态及数据一致性。
MySQL 5.7 默认启用 GTID（gtid_mode=ON），跳过单个事务错误必须用 SET GTID_NEXT + 空事务方式，sql_slave_skip_counter 直接报错不可用。
先确认是否真在 GTID 模式下
别凭经验猜，执行：SELECT @@gtid_mode, @@enforce_gtid_consistency;
两个值都必须是 ON。如果不是，说明你实际走的是传统 binlog 位置复制，方法完全不同——但 MySQL 5.7 官方安装包默认开 GTID，绝大多数情况就是 GTID 模式。
从 SHOW SLAVE STATUS\G 提取准确 GTID
重点不是看 Last_SQL_Error 的文字描述，而是找其中明确写出的 GTID 字符串，格式类似：a1b2c3d4-5678-90ab-cdef-1234567890ab:12345。
这个值必须严格匹配，包括大小写、冒号、分号都不能错。
常见错误现象：
• 把 Retrieved_Gtid_Set 里的一长串集合直接复制粘贴，结果跳过了多个事务
• 从 Exec_Master_Log_Pos 反推 GTID，但位置和 GTID 不是一一对应关系，容易错位
• 忽略了 Last_SQL_Error 末尾可能带空格或换行，导致 SET GTID_NEXT 执行失败
执行空事务覆盖指定 GTID
顺序不能乱，缺一不可：
• STOP SLAVE;
• SET GTID_NEXT = 'a1b2c3d4-5678-90ab-cdef-1234567890ab:12345';
• BEGIN; COMMIT;
• SET GTID_NEXT = 'AUTOMATIC';
• START SLAVE;
注意：
• BEGIN; COMMIT; 是必须的，不是可选；不执行就等于没消耗掉这个 GTID，启动后仍会重试原事务
• 不要加 START SLAVE IO_THREAD; 或单独启 SQL 线程，START SLAVE 就够了
• 如果复制已卡在多线程模式（slave_parallel_workers > 0），建议先设为 0 再操作，避免 GTID 分配混乱
跳过之后必须验证是否真恢复
看到 Slave_SQL_Running: Yes 不代表成功。
检查三项：
• Seconds_Behind_Master 是否开始下降，而不是卡在某个固定值
• Exec_Master_Log_Pos 是否持续推进，且与主库 SHOW MASTER STATUS 的 Position 差距不再扩大
• 主库执行一条可验证的 INSERT，例如：INSERT INTO test_verify VALUES (UNIX_TIMESTAMP(), 'skip_test');，立刻查从库有没有同步过来
最容易被忽略的点：跳过只是绕开问题，不是修复数据不一致。如果错误原因是人为在从库误删表或改数据，跳过之后主从记录数、校验和仍可能不一致，得后续用 pt-table-checksum 之类工具对账。
