Navicat 不记录字段级同步冲突详情，无专门冲突日志；Ctrl+H 仅显示操作时间戳，不包含SQL或冲突行信息；定位外键冲突需依赖 Compare & Preview 的 Difference 视图、MySQL general_log（需提前开启）及手动校验父表数据完整性。
Navicat 数据同步冲突发生后，日志在哪查？
navicat 本身**不记录数据同步过程中的字段级冲突详情**，也没有专门的“同步冲突日志”面板。你看到的所谓“历史记录”，其实是两类东西混在一起的：一类是用户操作痕迹（比如点过几次同步），另一类是数据库自身的通用日志（如 mysql 的 general log）。这两者都**不能直接告诉你哪条记录因外键冲突被跳过、哪一列值不一致、为什么 update 失败了**。
Ctrl+H 看到的是什么？它能帮上忙吗？
按 Ctrl+H 或点击【工具】→【历史日志】，打开的是 Navicat 客户端本地的操作历史——比如“2026-03-10 14:22 执行了 Data Synchronization”，仅此而已。它不会显示 SQL 语句、不会记录比对结果、更不会保存冲突行的主键值。这个日志只适合回溯“我是不是点错了按钮”，不适合排查“为什么 users 表没同步成功”。
真正能定位外键冲突的三个实操路径
要查清外键导致的同步失败，得绕开 Navicat 的 UI 日志，从底层入手：
- 同步执行时勾选
Compare & Preview，预览界面里点中报错的表 → 底部切换到 “Difference” 视图，这里会高亮显示源/目标同主键但字段值不同的行（含外键字段）； - 如果同步中途报错如
Cannot add or update a child row: a foreign key constraint fails，说明目标库外键约束拦住了插入/更新 —— 此时需确认：源表该记录引用的父表数据，在目标库是否存在？字段名、值、大小写、空格是否完全一致？ - 手动开启 MySQL 的
general_log（在 Navicat 中右键数据库 → 【General Log】→ 【Open General Log】），它会记录所有发往数据库的 SQL；但注意：它不区分来源，且默认关闭，需提前开启才有效，同步完再开就什么都看不到了。
为什么外键冲突常被误判为“数据不同步”？
因为 Navicat 同步逻辑默认以 Source 为准，但它**不做外键依赖检查**。比如源库 orders 表里某条记录指向 users.id=999，而目标库 users 表里根本没有 id=999 这条记录，Navicat 就会静默跳过这条订单，或直接报错中断 —— 它不会提醒你“父表缺失”，也不会自动把 users 补上。这种“漏同步”不是日志没记，而是同步策略本身不处理跨表依赖。
所以别指望翻日志找到答案，得在预览阶段盯紧 Key Mapping 是否用了真正有效的唯一键，同时确保外键关联的父表已先同步完成。这是最容易被忽略、也最常导致线上数据不一致的地方。
