主从同步报错 1062 时，最推荐的处理方式是确认从库数据一致后跳过引发错误的事务。适用场景为从库主键冲突且业务允许忽略该条变更，风险边界是跳过可能导致主从数据不一致，需人工核验。
先说结论：确认从库缺失数据已存在或无需同步后，通过设置跳过事务参数恢复同步。
- 先确认：检查报错 SQL 和从库实际数据是否冲突。
- 先处理：根据是否开启 GTID 选择 sql_slave_skip_counter 或 SET GTID_NEXT。
- 再验证：执行 SHOW SLAVE STATUS 确认 Seconds_Behind_Master 归零。
命令速用版
非 GTID 模式使用全局变量跳过，GTID 模式需注入空事务。
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
STOP SLAVE; SET GTID_NEXT='xxx-xxx-xxx:N'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
为什么会这样
报错 1062 表示从库尝试插入一条主键已存在的数据。常见原因是从库被手动写入数据，或主库重复执行了已同步的事务。
分步处理
第一步停止同步线程，防止错误累积。执行 STOP SLAVE; 命令。
第二步确认复制模式。查询 SHOW VARIABLES LIKE 'gtid_mode';，结果为 ON 则使用 GTID 方法，为 OFF 则使用计数器方法。
第三步执行跳过操作。非 GTID 模式执行 SET GLOBAL sql_slave_skip_counter = 1;。GTID 模式需提取报错事务 GTID，执行空事务注入。
第四步重启同步。执行 START SLAVE; 命令恢复复制。
怎么验证是否生效
执行 SHOW SLAVE STATUS\G 查看状态。关注 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master 数值逐渐减小至 0。
常见坑
GTID 模式下严禁使用 sql_slave_skip_counter，会导致 GTID 序列混乱。跳过错误前必须核对从库数据，避免静默丢失业务数据。
常见问题
跳过错误会导致数据丢失吗
会丢失该事务对应的变更。如果从库已有相同数据则无影响，否则从库将缺少该条记录。
如何获取报错事务的 GTID
查看从库错误日志或执行 SHOW SLAVE STATUS 查看 Last_Error 字段中包含的 GTID 信息。
参考来源
MySQL Official Documentation, Replication Slave Options and Variables, https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html
MySQL Official Documentation, Global Transaction Identifiers, https://dev.mysql.com/doc/refman/8.0/en/replication-gtids.html