MySQL主从复制中出现数据冲突，通常是因为主库和从库的数据不一致导致的。这类问题会影响复制的稳定性，必须及时处理。核心思路是识别冲突、分析原因、修复数据、恢复复制。以下是具体处理方式。
1. 识别复制冲突
当主从复制中断时，先通过命令查看错误信息：
SHOW SLAVE STATUS\G重点关注以下字段：
Last_Error：显示最近的错误信息，如“Duplicate entry”或“Can't find record” Slave_SQL_Running：若为No，说明SQL线程已停止 Exec_Master_Log_Pos 和 Relay_Master_Log_File：记录当前执行到的位置常见错误类型：
主键冲突（Duplicate entry for key 'PRIMARY'） 更新或删除时找不到对应记录（Could not find row） 表结构不一致导致插入失败2. 常见冲突场景及处理方法
根据错误类型选择合适的处理策略：
场景一：主键或唯一键冲突可能是人为在从库插入了与主库相同主键的数据。
确认从库多出的数据是否可删除，若可删，执行 DELETE 清理冲突行 或使用 REPLACE INTO / INSERT ... ON DUPLICATE KEY UPDATE 跳过 临时跳过错误（仅应急）： SET GLOBAL sql_slave_skip_counter = 1;START SLAVE; 场景二：删除操作在从库找不到记录
主库删除某行，但从库该行已不存在。
检查是否从库被手动修改过数据 确认无影响后，可跳过该事件（同上设置 sql_slave_skip_counter） 场景三：数据不一致但结构相同主从同一主键对应的数据内容不同。
以主库为准，将从库数据更新为与主库一致 可通过 pt-table-checksum 和 pt-table-sync 工具自动检测并修复3. 预防复制冲突的建议
避免从库被意外写入是关键。
从库配置 read_only=ON（推荐 super_read_only=ON 防止高权限用户写入） 定期使用 pt-heartbeat 监控复制延迟，防止积压引发冲突 主从切换时使用 GTID 模式，便于定位位置和一致性管理 变更表结构时，确保主从顺序执行，避免中间状态不一致4. 使用 GTID 模式简化冲突处理
启用 GTID 后，可以通过指定事务跳过错误。
查看错误事务的 GTID 注入空事务跳过： STOP SLAVE;SET GTID_NEXT='caa5eaf5-ebcd-11ec-8e4b-0242ac110002:100';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;
这样可精准跳过特定事务，避免误操作。
基本上就这些。关键是快速响应错误日志，判断是否能安全跳过或需手动修复。长期来看，规范操作流程和只读设置能大幅降低冲突概率。
