Navicat 不具备监听数据源变更能力，其同步功能依赖外部机制驱动和手动构造增量条件；它仅支持批处理式任务，无内置binlog订阅、CDC或消息队列集成，需通过时间戳或自增ID配合脚本实现模拟增量同步。
navicat 本身不监听数据源变更，无法自动感知“变化发生”，所谓“有变化才同步”必须靠外部机制驱动 + 手动构造可判定的增量条件。
为什么 Navicat 没有“监听变更后触发”功能
Navicat 的 Data Synchronization 和 Data Transfer 都是**批处理式任务**，不是持续监听服务。它没有内置 binlog 订阅、触发器钩子或 CDC 能力，也不集成消息队列。每次运行都是一次独立的全表扫描（除非你加了过滤）。所谓“变化触发”，实际是人定时去跑、或用脚本判断“是否有新数据”后再调用同步。
用时间戳字段 + 外部判断模拟“变化触发”
这是最常用也最可控的方式，前提是源表有可靠、单调推进的时间字段（如 created_at 或 updated_at）。
- 在同步配置的「表映射 → 过滤条件」里写：
created_at > '2026-06-04 00:00:00'（注意单引号不能少） - 每次同步前，先查源表最大时间值：
SELECT MAX(created_at) FROM orders;，把结果记下来，作为下一次的过滤起点 - 如果要用命令行自动跑，就得写脚本：先连源库查
MAX(created_at)，拼出带时间的.nsx文件路径或临时改配置，再调navigator.exe -sync - 时区必须一致：确认源库
SELECT @@time_zone、Navicat 客户端设置、以及你手动填的时间字符串三者时区相同，否则会漏数据或重复
用自增 ID 替代时间戳的注意事项
当源表无时间字段但有单调递增的 id（比如 AUTO_INCREMENT 且从不删除/重用），可用它做增量锚点，但要格外小心：
- 过滤条件写成：
id > 10500，而不是id BETWEEN 10001 AND 10500（后者易漏或重） - 同步完成后立刻执行：
SELECT MAX(id) FROM orders;，把结果存为下次起点——Navicat 不保存也不更新这个值 - 如果源表发生过 DELETE + INSERT 导致 id 不连续，或用了 REPLACE INTO / ON DUPLICATE KEY UPDATE，
MAX(id)就不可靠，此时必须切回时间字段 - 目标表主键也得是
id，且类型一致（比如都是BIGINT UNSIGNED），否则 Navicat 匹配失败，退化为全量插入
真正“变化触发”的替代方案（绕开 Navicat）
如果你真需要数据库一变就同步，Navicat 不是合适工具。更现实的做法是：
- MySQL 场景：用
mysqldump --where="updated_at > '2026-06-04 00:00:00'"+ 定时脚本 +mysql导入，比 Navicat 更轻量、更可控 - 生产级需求：上 Debezium + Kafka 做 CDC，下游消费写目标库——这才能做到毫秒级响应变更
- 定时轮询仍是主流：用 crontab 或 Windows 任务计划，每 5 分钟跑一次带时间过滤的 Navicat 同步，关键不是频率，而是每次过滤条件里的值是否被正确更新
最容易被忽略的点：过滤值不会自动更新。哪怕你设了每天凌晨 2 点同步，如果没手动把 created_at > '2026-06-04 00:00:00' 改成 '2026-06-05 00:00:00'，第二天还是同步昨天的数据——看起来像“没触发”，其实是条件僵死。
