主从复制冲突本质是从库已有数据与主库binlog写操作不兼容，导致SQL线程中断；常见类型包括主键重复（1062）、记录不存在（1032）及表结构不一致，需按场景精准处理而非盲目跳过。
主从复制冲突的本质是啥
MySQL 主从复制本身不解决冲突，它只是单向同步：从库被动执行主库的 binlog。所谓“冲突”，其实是从库上已有数据与主库发来的写操作不兼容，比如 INSERT 主键重复、UPDATE 影响 0 行、DELETE 找不到记录等。这些在从库报错后会直接中断 SQL 线程（Seconds_Behind_Master 变为 NULL），不是“自动处理”，而是“卡住等你修”。
常见冲突类型及对应跳过策略
不能一概用“跳过错误”，得看场景：
-
主键/唯一键冲突（1062 错误）：主库插入一条记录，但从库已存在同主键值（比如从库被手动写入过）。此时可临时跳过：
SET GLOBAL sql_slave_skip_counter = 1;（仅适用于STATEMENT格式）；更安全的是用gtid_next跳过单个 GTID：SET gtid_next='xxx-xxx-xxx:12345'; BEGIN; COMMIT; SET gtid_next='AUTOMATIC'; -
找不到记录（1032 错误）：主库执行了
UPDATE或DELETE，但从库该行不存在。原因常是主库删了又插，或从库被误删。跳过前建议先查SHOW SLAVE STATUS\G的Exec_Master_Log_Pos和Relay_Log_File，确认上下文再决定跳还是补数据。 -
表结构不一致导致的执行失败：比如从库少一个字段，主库却往里插值。这种不能跳过，必须先对齐表结构（
ALTER TABLE），否则后续所有涉及该列的操作都会持续报错。
避免冲突比修复更重要
很多冲突其实源于架构或运维疏漏：
- 从库禁止写入：确保
read_only=ON（注意：超级用户仍可写，必要时加super_read_only=ON） - 主库避免非确定性语句：如
INSERT ... SELECT没带ORDER BY，或用了NOW()、UUID()等函数，在STATEMENT复制模式下会导致主从数据不一致 - 慎用
auto-increment：多主或分片场景下，若未配置auto_increment_offset和auto_increment_increment，极易出现主键冲突 - 监控要盯紧
Seconds_Behind_Master和Slave_SQL_Running_State，一旦变成NULL或Waiting for master to send event后长期不动，大概率已出错
GTID 模式下处理冲突更可控但门槛更高
开启 gtid_mode=ON 后，每个事务有唯一 ID，跳过指定事务比靠偏移量更精准。但要注意：
- 所有节点必须统一开启 GTID，且
enforce_gtid_consistency=ON，否则启动失败 - 跳过事务必须在从库停掉复制后操作：
STOP SLAVE;→SET gtid_next='xxx:yyy';→BEGIN; COMMIT;→SET gtid_next='AUTOMATIC';→START SLAVE; - 如果主库已删除某个 GTID 对应的 binlog（比如 purge 过早），从库重连时可能因找不到日志而无法继续，这时得考虑重建从库
