GTID模式下必须用SET GTID_NEXT+空事务跳过1062错误，禁用sql_slave_skip_counter；先执行SHOW VARIABLES LIKE 'gtid_mode'确认模式，再查SHOW SLAVE STATUS\G定位卡住的GTID，漏抄或COMMIT中断将导致复制永久断裂。
1062 报错不能直接跳过，必须先确认是否启用了 GTID —— 这是所有操作的前提。盲目用 sql_slave_skip_counter 在 GTID 模式下会失败，甚至让复制彻底断裂。
怎么看自己是不是 GTID 模式
执行 SHOW VARIABLES LIKE 'gtid_mode';，如果返回 ON，就说明已启用 GTID；再看 SHOW MASTER STATUS; 中的 Executed_Gtid_Set 是否非空，也能佐证。
常见错误现象：执行 SET GLOBAL sql_slave_skip_counter = 1; 后报错 ERROR 1794 (HY000): The slave is configured with slave_exec_mode = IDENTITY but GTID mode is enabled，这就是 GTID 已开但你还想走老路的典型信号。
- GTID 模式下唯一合法跳过方式是注入空事务：
SET GTID_NEXT='xxx:N'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; - 传统点位模式（
gtid_mode=OFF）才允许用sql_slave_skip_counter，且仅对binlog_format=STATEMENT稳定有效 - 配置文件里加
slave-skip-errors=1062虽然能“一劳永逸”，但它是静态参数，改完必须重启 MySQL，线上环境基本不可行
跳过前必须查清卡在哪条 GTID
运行 SHOW SLAVE STATUS\G，重点关注三处：
-
Retrieved_Gtid_Set：从库已拉取但未执行的 GTID 集合 -
Executed_Gtid_Set：从库已实际执行过的 GTID 集合 -
Retrieval_Gtid_Set和Executed_Gtid_Set的差集，就是当前卡住的那个事务的 GTID
漏抄、抄错一位字符、或 COMMIT 前连接断开，都会导致从库 GTID 状态永久错乱 —— 此时只能重建从库。
跳过只是临时手段，真正要盯紧的是写入源头
1062 不是孤立事件，它背后大概率存在以下问题之一：
- 从库被绕过
read_only=ON写入了数据（检查SELECT @@read_only;和实际是否有 DML 日志） - 应用层双写主库和从库（比如某些 ORM 自动 fallback 到从库执行 INSERT）
- 主库 binlog 写入与从库 SQL 线程执行之间存在时间差，而应用又没做幂等控制
比跳过更关键的动作是：立即查审计日志（如 general_log 或 Percona 的 slow-log 扩展），定位那条在从库重复插入的语句是从哪来的。否则跳过一次，下次还会来。
数据不一致时优先修复而非跳过
如果确认冲突记录主从内容一致（比如主库 INSERT 的值和从库已有行完全相同），可以跳过；但如果从库那行数据是旧的、错的，或者主库那条 INSERT 实际该更新不该插入，那就不能跳。
此时应手动修复：
- 先关写入：
SET SQL_LOG_BIN = 0; - 删掉从库冲突行：
DELETE FROM table_name WHERE id = ?; - 再开写入：
SET SQL_LOG_BIN = 1; - 最后
START SLAVE;
注意：Master-Master 架构下，这一步必须加 SET SQL_LOG_BIN = 0，否则删操作会反向同步到主库，引发更大问题。
