Navicat数据同步不能用于修复主从不一致，因其全量覆盖会绕过binlog、破坏复制链路；应先验证是否为延迟假象，再按差异规模选择SQL修补、pt-table-checksum校验或重建从库。
不能直接用Navicat数据同步“修复”主从不一致——它不是为实时主从修复设计的，强行用会覆盖从库增量、破坏复制链路。 真正安全的做法是：先确认不一致是否由复制延迟或误操作导致，再决定用同步、SQL修补，还是重建从库。
为什么数据同步不适合主从修复场景
Navicat数据同步默认以Source为准全量覆盖Target，而主从架构中从库本应只读、被动接收binlog。若把主库设为Source、从库设为Target并启用Update/Insert/Delete，会直接绕过复制机制：
- 它生成的SQL不走binlog，主库无法感知从库变更，后续主从状态彻底脱节
- 若从库已有应用写入（比如被误设为可写），同步会无差别覆盖这些合法变更
- 预览里标为
Insert的行，可能只是从库因延迟还没收到主库的INSERT，而非真实缺失 - 同步过程不校验GTID或binlog position，无法保证一致性断点
先判断不一致是真差异还是假警报
主从数据不一致，80%以上是复制延迟或临时状态，不是数据损坏。别急着同步，先做三件事：
- 在从库执行
SELECT @@gtid_executed，主库也执行，用GTID_SUBSET()验证是否完全包含；返回1才说明已追平 - 查表级元数据时间戳：
SELECT UPDATE_TIME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'，主从必须一致 - 对关键表跑一次
pt-table-checksum（推荐），或手动比对主键分布：SELECT COUNT(*), MIN(id), MAX(id) FROM t，看数量和范围是否匹配
确认是真实不一致后，选对修复方式
根据差异规模和业务容忍度，选下面一种：
- 单表少量行不一致（如几百条）：用Navicat导出差异SQL，人工审核后在从库执行
INSERT IGNORE INTO或REPLACE INTO，不走同步向导 - 多表中等差异（如数千行）：用
mysqldiff或自写JOIN查询定位差异行，生成UPDATE/DELETE语句，在从库禁用sql_log_bin=0后执行 - 全库或大表严重不一致：停从库，用
mysqldump --single-transaction --master-data=2重拉，比任何同步工具都可靠
如果坚持要用Navicat同步，必须绕过这些坑
仅限测试环境或明确接受风险的场景，且必须满足以下全部条件：
- 从库已
STOP SLAVE，且Seconds_Behind_Master = 0+GTID_SUBSET()验证通过 - 同步方向设为
Master → Slave，但勾选选项里只启用Insert records和Update records，绝对禁用Delete records - Key Mapping页每张表必须精确映射到主键字段（如
id），复合主键要全选，且确认两边字段类型一致（INTvsBIGINT会失效） - Options → Error Handling中启用
Skip duplicate key errors（仅Navicat 15+），否则Duplicate entry for key 'PRIMARY'会中断
最常被忽略的一点：Navicat同步日志里不会列出被Skip的具体主键值，你得自己在预览的Difference标签页里逐表检查标为Insert的行，对照从库确认是否真缺失。
