确认模式看auto_position：为1是gtid（禁用sql_slave_skip_counter），为0是传统复制（可用sql_slave_skip_counter=1）；gtid跳过需三步：stop slave、set gtid_next='xxx'; begin; commit;、验证gtid_subtract为空且slave_sql_running: yes。
能跳，但必须分清是传统复制还是GTID模式——两者操作完全不同，混用会直接报错或卡死。
怎么确认当前是GTID还是普通复制？
直接查 SHOW SLAVE STATUS\G，看 Auto_Position 字段：
- 值为
1→ GTID 模式（不能用sql_slave_skip_counter） - 值为
0→ 普通基于 position 的复制（可用sql_slave_skip_counter）
别只看 GTID_EXECUTED 是否有内容——有些旧版本即使开了 GTID，Auto_Position 仍可能为 0。这个字段才是唯一权威判断依据。
GTID模式下跳过单个事务：三步缺一不可
核心动作不是“跳”，而是“伪造一个已执行的同ID事务”。漏掉任意一步都会导致 ERROR 1840 (HY000) 或卡在 Waiting for master to send event。
- 先
STOP SLAVE，再立刻执行SET GLOBAL slave_parallel_workers = 0（必须确认返回值是 0，否则多线程下GTID_NEXT无效） - 从
Last_SQL_Error或Retrieved_Gtid_Set与Executed_Gtid_Set差集中提取出目标 GTID，例如aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:123 - 执行：
SET GTID_NEXT = 'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:123';→BEGIN; COMMIT;（注意：必须是空事务，且必须提交；DDL 如CREATE TABLE在部分版本有兼容性风险）
执行完别急着 START SLAVE，先 SELECT @@GTID_NEXT; 确认没被自动重置成 AUTOMATIC——这是会话级变量，换连接就失效。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
传统复制（Auto_Position=0）下跳过一个事务
简单但危险：它跳的是 relay log 里的“下一个事务”，不校验内容，容易误跳。
- 确认
Slave_SQL_Running: No且Last_SQL_Errno非 0（如1008、1062） - 执行
SET GLOBAL sql_slave_skip_counter = 1;（仅对下一个事务生效，不会持久化） - 再
START SLAVE，观察Seconds_Behind_Master是否开始下降
注意：sql_slave_skip_counter 在 GTID 模式下会被忽略，且 MySQL 8.0.23+ 已标记为 deprecated，新环境尽量避免依赖它。
最容易被忽略的验证点
注入空事务后，Executed_Gtid_Set 不会立刻变——这是正常现象。MySQL 只在重放 relay log 时更新它。真正要验证的是：
-
SELECT GTID_SUBTRACT('target-gtid', @@global.gtid_executed);返回空集合（''），说明该 GTID 已被包含 -
SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes且Seconds_Behind_Master不再为NULL - 不要只看
Retrieved_Gtid_Set和Executed_Gtid_Set差集缩小——得确认差集里确实少了那个目标 GTID
跳过本身很快，但确认“它真被跳过了”需要两步验证：GTID 集合减法 + 复制线程状态，少一步都可能埋下数据不一致隐患。
