Navicat跨库同步失败需分三处查日志：一是任务右键View Log查看本次控制台输出；二是检查%AppData%\PremierSoft\Navicat Premium\logs\下batchjob.log和navicat.log（启动即覆写）；三是依赖Compare&Preview预览结果确认变更内容，因其不落盘但决定实际操作。
navicat 跨数据库同步失败时，日志不在一个地方，也没有统一入口——必须分三处手动检查，缺一不可。
同步任务自身的「Last Run Log」在哪里找
这是最直接、最常被忽略的日志来源。它只记录本次执行的完整控制台输出，包括连接建立、表比对、SQL 执行、报错堆栈等。
- 在 Navicat 主界面左侧「自动运行」或「计划任务」列表中，右键目标同步任务 → 选择
View Log - 如果没看到日志内容，说明任务根本没触发（不是失败，是没跑），需转向系统级排查
- 常见错误信息会明确出现，比如
ERROR: duplicate key violates unique constraint或ERROR 1045 (28000): Access denied for user，这些都来自此处 - 注意：该日志不持久，每次新执行会覆盖前一次，且无法导出为文件（仅可复制）
主程序日志文件路径和覆写风险
Navicat 的全局操作日志（含同步模块初始化、连接池状态、异常中断）存在本地磁盘，但默认每启动一次就清空重写，极易丢失线索。
- Windows 路径：
%AppData%\PremierSoft\Navicat Premium\logs\batchjob.log和navicat.log - macOS 路径：
~/Library/Application Support/PremierSoft/Navicat Premium/logs/ - 关键限制：这些文件在 Navicat 启动时会被截断（truncate），不是追加写入；若同步失败后你重启了 Navicat，日志就没了
- 实用技巧：发现同步异常后，立刻关闭 Navicat，再用记事本/VS Code 打开
batchjob.log查看末尾几行，重点关注[BatchJob]前缀的段落
为什么 Compare & Preview 界面比日志还关键
Navicat 同步是“预计算变更”模型，真正决定改什么、删什么、插什么的，不是日志里写的“执行了 UPDATE”，而是执行前 Compare & Preview 界面里你点确认的那一瞬。
- 同步失败常因预览阶段已存在冲突（如目标库有源库没有的主键值），但用户跳过了预览直接点
Deploy，日志只会显示“INSERT failed”，不会告诉你“因为目标表第 7 行 id=123 已存在” -
Compare & Preview中选中某张表，底部并排显示源/目标记录，冲突字段高亮，勾选框可逐条排除——这个操作本身不写日志，只存在内存里 - 如果你没保存 profile，下次重跑就得重新比对；而比对过程完全不落盘，失败后无法回溯“当时到底识别出几条差异”
如何补一手可靠审计（不依赖 Navicat 日志）
Navicat 不提供变更明细持久化，想事后还原“哪张表、哪几行、什么时候被同步覆盖”，必须自己动手建轻量审计机制。
- 同步前，在目标库执行快照 SQL，例如：
SELECT 'orders' AS table_name, COUNT(*) AS cnt, MD5(GROUP_CONCAT(id ORDER BY id)) AS chk FROM orders; - 把结果连同任务名、
NOW()时间戳插入一张sync_audit表，结构简单即可：task_name VARCHAR(100), table_name VARCHAR(64), cnt BIGINT, chk CHAR(32), sync_time DATETIME - 同步失败后，对比失败前后快照的
cnt和chk，能快速定位是否部分写入、是否主键冲突导致中断、甚至误删 - 注意：别依赖 MySQL 的
general_log，开启后性能损耗 5%~10%，且它记录的是所有语句，不是 Navicat 同步逻辑产生的 DML
真正麻烦的不是日志找不到，而是 Navicat 同步失败时，可能连“有没有开始执行”都难以判断——View Log 为空？那大概率是计划任务根本没触发；batchjob.log 里只有启动记录？那可能是轻量模式禁用了后台模块；Compare & Preview 没保存 profile？那连“当时识别出哪些差异”都成了黑盒。
