必须先确认gtid模式：执行show variables like 'gtid_mode'，返回on才启用gtid；若为on，则禁用sql_slave_skip_counter，须严格按stop replica→set gtid_next→begin;commit→set gtid_next='automatic'→start replica五步注入空事务跳过冲突，漏一步或抄错gtid将致复制永久中断。
别急着跳过，先确认是不是 GTID 模式——这是所有操作的分水岭，错一步复制就永久中断。
怎么快速判断自己是不是 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、从库没开，或反之，都会导致复制卡在 1062 且无法跳过。
GTID 模式下必须用 SET GTID_NEXT 注入空事务
这不是“跳过下一条”，而是“伪造已执行”那个冲突事务的 GTID，让 SQL 线程跳过它。漏掉任一环节，GTID 集合就会永久错乱，重建从库是唯一选择。
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，形如3e11fa47-71ca-11e1-9e33-c80aa9429562:23，冒号前后不能有空格，大小写必须完全一致 - 停 SQL 线程：
STOP REPLICA;（MySQL 8.0.22+ 推荐用REPLICA，SLAVE已弃用） - 注入空事务：
SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';→BEGIN;→COMMIT;（必须是空事务，不能带任何 DML） - 重置并重启：
SET GTID_NEXT = 'AUTOMATIC';→START REPLICA;
如果 GTID_NEXT 值抄错一位、或 COMMIT 前连接意外断开，从库将进入不可恢复的 GTID 不一致状态。
非 GTID 模式下别硬用 sql_slave_skip_counter
SET GLOBAL sql_slave_skip_counter = 1 只对 binlog_format = STATEMENT 稳定有效；ROW 格式下执行会报 ERROR 1374，且它跳的是“下一条事件”，不是当前错误那条，极易引发后续数据错位。
更稳妥的做法：
- 先停 SQL 线程：
STOP SLAVE SQL_THREAD; - 从
SHOW SLAVE STATUS\G中取Relay_Master_Log_File和Exec_Master_Log_Pos - 用
mysqlbinlog解析对应 binlog，确认冲突 SQL 内容，再决定是删从库脏数据，还是手动执行修复语句
禁用 slave-skip-errors = 1062 配置项——它需重启 MySQL，线上不可行，还会掩盖所有 1062，让不一致静默扩大。
跳过之后三件事不能省
跳过只是恢复同步的起点，不是终点。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 集合错乱”状态，此时重建从库是唯一选择，没有补救命令。
