跳过error 1062不是恢复终点，而是数据不一致的明确信号；gtid模式下必须用set gtid_next注入空事务跳过，非gtid模式下sql_slave_skip_counter仅对statement格式稳定有效，且易引发错位。
直接跳过 ERROR 1062 不是恢复复制的终点，而是数据已不一致的明确信号；跳过操作本身极易引发 GTID 错乱或后续错位，必须先确认模式、再严格按路径执行。
先查 gtid_mode 再决定能不能用 sql_slave_skip_counter
执行 SHOW VARIABLES LIKE 'gtid_mode'; —— 返回 ON 就说明启用了 GTID 模式，此时 SET GLOBAL sql_slave_skip_counter = 1 会立刻报错 ERROR 1858 或 ERROR 1251，不是命令输错了，是 MySQL 8.0.23+ 已彻底弃用该变量。
常见误判：
- 看到
SHOW SLAVE STATUS\G中Executed_Gtid_Set非空，就以为开了 GTID —— 实际可能是旧从库残留值，必须以gtid_mode变量为准 - 主库开 GTID、从库没开，会导致复制卡在
1062且无法跳过
GTID 模式下必须用 SET GTID_NEXT 注入空事务
跳过本质是“伪造已执行”，靠注入一个空事务消耗掉冲突事务的 GTID。漏一步、抄错一位字符（比如大小写、冒号前后空格），GTID 集合就永久错乱，只能重建从库。
操作顺序不可调换：
- 从
SHOW SLAVE STATUS\G的Last_SQL_Error字段提取完整 GTID，形如3e11fa47-71ca-11e1-9e33-c80aa9429562:23，注意大小写、冒号、无空格 -
STOP REPLICA;（MySQL 8.0.22+ 推荐用REPLICA，SLAVE已弃用） SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';-
BEGIN; COMMIT;（必须是空事务，不能带任何 DML；连接断在COMMIT前会导致 GTID 集合不完整） SET GTID_NEXT = 'AUTOMATIC'; START REPLICA;
非 GTID 模式下别硬套 sql_slave_skip_counter
sql_slave_skip_counter 仅对 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 不是孤立错误，而是主从数据已不一致的明确信号。跳过一次，下次大概率在别的表、别的字段上爆发。最常被忽略的一点：人为在从库误写入、主库用了 INSERT IGNORE 但从库没走同样逻辑、或主从切换后 position/GTID 混乱导致重复执行 —— 这些根因不查清，跳过只是把问题埋得更深。
