mysql 8.0.23+默认启用gtid，sql_slave_skip_counter已禁用；必须先执行show variables like 'gtid_mode'确认为on，再严格按stop slave→set gtid_next→begin;commit→set gtid_next='automatic'→start slave五步跳过，漏一步或抄错gtid将导致复制永久中断。
直接跳过 sql_slave_skip_counter 在绝大多数生产环境会失败，甚至导致复制永久中断——因为你大概率已启用 GTID（MySQL 8.0.23+ 默认开启），而该变量在 gtid_mode = ON 时被彻底禁用。
先确认是不是 GTID 模式
这是所有操作的分水岭，错一步全盘失效：
- 执行
SHOW VARIABLES LIKE 'gtid_mode';，返回ON就必须走 GTID 跳过流程 - 别信
Executed_Gtid_Set非空就认为开了 GTID——旧从库残留值很常见，gtid_mode变量才是唯一权威依据 - 如果执行
SET GLOBAL sql_slave_skip_counter = 1;报错ERROR 1858或ERROR 1794，说明 GTID 已启用，立刻停手
GTID 模式下必须用 SET GTID_NEXT 注入空事务
这不是“跳过下一条”，而是“伪造已执行”那个卡住的 GTID，让 SQL 线程跳过冲突点。漏掉任一环节，GTID 集合就会永久错乱：
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，例如：gtid:3e11fa47-71ca-11e1-9e33-c80aa9429562:23（注意冒号前后无空格、大小写严格一致） - 顺序执行五步，缺一不可：
STOP SLAVE;→SET GTID_NEXT = 'xxx:nnn';→BEGIN;→COMMIT;→SET GTID_NEXT = 'AUTOMATIC'; START SLAVE; -
BEGIN; COMMIT;必须是空事务——不能带任何 DML，也不能在 COMMIT 前断开连接，否则从库 GTID 状态不可恢复
跳过之后三件事不能省
跳过只是恢复同步的起点，不是终点。1062 是症状，不是病因：
- 查源头：用
mysqlbinlog --base64-output=DECODE-ROWS -v解析报错对应 binlog，确认那条 INSERT 是谁、何时、为何发到从库（比如应用双写、从库误开read_only = OFF） - 清脏数据：如果从库多出的记录是人为误插，且业务允许，优先执行
SET sql_log_bin = 0; DELETE FROM 表名 WHERE 主键 = X;，比跳过更安全、可追溯 - 校一致性：跳过或清理后，必须用
pt-table-checksum或人工比对关键表主键范围，确认主从数据真正对齐
最常被忽略的一点：GTID 值抄错一位、COMMIT 前连接意外中断、或在非 GTID 环境误用了 GTID 流程——这三类操作都会让从库进入“GTID 集合错乱”状态，此时重建从库是唯一选择，没有补救命令。
