Navicat 无法真正实现可靠每日增量同步，必须依赖系统级调度器（如Windows任务计划程序）调用命令行执行已保存的同步配置（.nsx/.ncx），并手动更新WHERE条件中的时间戳或主键值，否则将导致漏数据、重复同步或全量重放。
Navicat 本身没有真正的“计划任务”后台服务，所谓每日自动增量同步，必须靠外部调度 + 命令行调用 + 手动构造增量条件三者配合。单独点“自动运行”或勾选“定时执行”根本不可靠——软件一关、窗口一失焦、系统一锁屏，任务就停摆。
为什么不能直接用 Navicat 的「自动运行」功能？
navicat 的「自动运行」只是客户端前台轮询机制：它只在 navicat 窗口处于活动状态且未最小化时，按设定间隔尝试触发一次同步。这不是操作系统级定时器，不依赖 windows task scheduler 或 cron。实际表现是：
- 你下班关掉 Navicat，凌晨三点的同步就彻底消失
- 远程桌面断开后，任务立即中断（即使进程还在）
- Windows 用户切到其他应用超过 30 秒，后续轮询大概率被系统挂起
真正能跑通的方案，只有让系统级调度器（如 Windows 任务计划程序）去调用 navigator.exe 或 navicat CLI，并传入已保存的同步配置文件。
如何用命令行 + 任务计划实现稳定每日增量同步？
核心路径是：GUI 中配好同步 → 导出为 .nsx（Windows）或 .ncx（macOS/Linux）→ 命令行验证 → 注册进系统计划任务。关键实操点：
- 同步配置里必须关闭「删除目标中不存在的记录」，否则每天都会清空历史数据
- 在「表映射」页对每张表点
Options→ 勾选Use WHERE condition，填类似created_at > '2026-06-01 00:00:00'（注意单引号） - Windows 下测试命令：
"C:\Program Files\PremiumSoft\Navicat Premium 16\navigator.exe" -sync "D:\sync\order_sync.nsx"；路径含空格必须加英文双引号 - 任务计划中务必勾选「不管用户是否登录都要运行」和「使用最高权限运行」，否则常见
Failed to load job: Permission denied - macOS/Linux 用户注意：
navicatCLI（v16+）不支持直接运行.nsx同步作业，只能用-backup/-restore，增量同步需退回到 Windows 虚拟机或改用mysqldump+mysql脚本
WHERE 条件怎么写才不会漏数据或重复同步？
增量逻辑成败全系于此。Navicat 不会自动更新时间值，每次同步后你都得手动改这个条件——这是最容易被忽略的致命点。
- 别用
BETWEEN '2026-06-01' AND '2026-06-02'：边界秒级数据可能因写入延迟被漏掉 - 推荐写法：
created_at > '2026-06-01 00:00:00'（硬编码上一日零点），或更稳妥的created_at > DATE_SUB(NOW(), INTERVAL 1 DAY)（仅限 MySQL 源库） - 如果表有
id自增主键且严格单调，可用id > 1234567，但必须每次同步后查源表最大id并更新该值 - 跨时区场景下，
NOW()返回的是 Navicat 客户端所在时区时间，若源库用 UTC，就得写created_at > CONVERT_TZ(NOW(), '+08:00', '+00:00')，否则必漏数据
字符集、主键、冲突处理这三项不校准，同步等于白做
同步显示“成功”，但目标库中文变问号、字段错位、重复插入报错——问题几乎全出在这三项。
- 两个连接的「高级」设置里，
Character set必须显式设为相同值（如utf8mb4），不能一个留空一个填utf8 - 「匹配字段」必须手动确认：如果源表主键是
order_id（UUID），目标表却是id（自增），Navicat 默认无法关联，得在映射界面取消Match fields by name，手动指定order_id→order_id - 「冲突处理」必须选「更新现有记录」，不能选「跳过」——否则源里改过的行，目标库永远不变；也不能选「停止」，否则一条冲突就中断整批
最常被跳过的动作，是同步完成后立刻去源库执行 SELECT MAX(created_at) FROM orders，把结果复制进下一次的 WHERE 条件。没这一步，所谓“每日增量”，只是每日全量重放一遍。
