Navicat无集中式同步历史面板，日志分散且不持久；需右键任务→View Log查单次输出，但仅含执行摘要；真正变更明细依赖执行前Compare&Preview预览；要获取可靠日志须手动开启DebugLog=1和LogLevel=3；生产环境追溯变更需数据库层自建审计（如快照表、binlog解析或触发器）。
navicat 没有集中式、可回溯的数据同步历史面板，日志分散且默认不持久——想查某次同步到底干了什么，得提前知道该看哪几处、怎么设、为什么不能只靠界面点一下。
数据同步任务自身的输出日志在哪看
每次手动或调度触发「数据同步」后，任务配置界面右下角会显示 Last Run Status 和 Last Run Time。只有点开该任务 → 右键 → View Log，才能看到本次执行的完整控制台输出：
- 连接是否成功（含 host/port/user）、源/目标表名、处理行数（
Inserted: 12, Updated: 3, Skipped: 1） - 报错详情（如
ERROR: duplicate key violates unique constraint "users_pkey"） - 但该日志是临时的：关掉窗口就丢，不自动存档
为什么不能只信这个日志，而必须依赖 Compare&Preview
Navicat 的同步逻辑是「预计算差异 + 执行」，真正决定变更内容的不是日志，而是执行前的 Compare & Preview 结果：
- 预览界面里选中某张表，底部并排显示源/目标记录，冲突字段高亮，支持逐条勾选跳过（比如主键重复但业务上不该覆盖）
- 日志里只写“Updated 5 rows”，但从不告诉你更新了哪 5 行、哪几列被改了——这些信息只存在于预览阶段的内存中
- 常见错误：直接点
Compare & Deploy跳过预览，结果误删目标库独有数据，事后翻日志也还原不出删了哪些
如何让日志真正可用（非默认状态）
Navicat 默认不记录 SQL 执行细节和同步过程快照，要获取可靠日志，必须主动开启调试模式并配合外部手段：
- 关闭 Navicat，在配置文件
config.ini的[General]段添加：DebugLog=1和LogLevel=3，重启后生成navicat_debug_YYYYMMDD.log - 日志路径固定：
%APPDATA%\PremierSoft\Navicat Premium\logs\（Windows）或~/Library/Application Support/PremierSoft/Navicat Premium/logs/（macOS） - 关键搜索词：
Connection timed out、Schema mismatch、Query execution timeout——界面提示太简略，没上下文 - 注意：
LogSynchronize.txt文件存在，但它只记录同步动作启动/结束时间，不包含变更明细，且每次同步都会覆盖
生产环境真正能追溯变更的唯一办法
Navicat 不提供审计能力，也不解析 binlog 或写入变更日志表。如果需要确认「谁在什么时间同步了什么」，必须在数据库层自己动手：
- 同步前手动快照关键表：
SELECT 'users' AS table_name, COUNT(*) AS cnt, MD5(GROUP_CONCAT(id ORDER BY id)) AS chk FROM users;，结果存进自建sync_audit表，关联任务名和时间戳 - MySQL 源库开启
log_statement = 'mod'或用SHOW BINLOG EVENTS定位同步窗口内的 DML - PostgreSQL 目标库建触发器记录
INSERT/UPDATE/DELETE，但要注意性能开销
所有这些都得提前部署——等出问题再补，日志早就没了，预览页也关掉了。
