Navicat 17 不支持定时同步和字段级增量更新，仅支持基于主键/唯一键的整行同步；需依赖数据库变更标记（如 updated_at）配合外部调度器实现伪增量。
Navicat 17 本身不支持“定时同步”或“仅更新变更字段”
Navicat 17 没有内置调度器，也不做字段级差异比对——它只在 Data Synchronization 向导中按整行（主键或唯一键）判断记录是否需 INSERT/UPDATE，不识别单个字段值是否真的变了。所谓“增量”，实际是靠你手动加 WHERE 条件过滤行，而非自动检测字段变更。
必须用外部调度器 + 手动构造时间戳条件
要实现“定时+只同步变更数据”，得拆成两步：先让数据库自己标记变更，再让 Navicat 按标记拉取。常见做法如下：
- 确保源表有可信赖的变更标记字段，例如
updated_at（DATETIME类型，每次UPDATE自动更新）或version（整型，应用层递增） - 在
Data Synchronization向导 Step 2 的Where Condition栏里填：updated_at > '2026-09-06 18:30:00'（注意用单引号包裹，且时间格式严格为YYYY-MM-DD HH:MM:SS） - 导出为脚本后，交由操作系统调度：Windows 用任务计划程序调用
.bat，Linux/macOS 用cron调用.sh - 每次调度前，需人工更新时间阈值（或写脚本动态生成），Navicat 不会自动维护上次同步时间点
为什么不能直接勾选“增量同步”？
Navicat 界面里根本没有叫“增量同步”的选项开关。部分用户误以为 Options → Update records 就是增量，其实它只是允许覆盖整行——哪怕只有 phone 字段变了，也会把整条记录 UPDATE 到目标库，其他字段哪怕没变也被重写一遍。容易踩的坑包括：
- 目标库有触发器或审计日志，会因无意义的全字段更新被反复触发
- 若源库
updated_at未设为ON UPDATE CURRENT_TIMESTAMP，该字段不会自动更新，条件就失效 - 跨库同步时（如 MySQL → SQL Server），时间类型精度不一致（MySQL 微秒 vs SQL Server 毫秒），可能导致漏同步
-
WHERE条件填错格式（比如写成updated_at > NOW() - INTERVAL 1 HOUR）会直接报错，Navicat 不支持函数式条件
真正可控的字段级更新只能靠数据库原生能力
如果你真需要“只更新变更字段”，Navicat 不是合适工具。应转向：
- 数据库自带的 CDC 机制：MySQL 的
binlog+ROW格式、SQL Server 的Change Tracking，配合自定义消费者 - 专用同步工具：如
Liquibase（结构+数据变更追踪）、Debezium（实时流式捕获） - 应用层双写+幂等设计：在业务代码里显式控制哪些字段需要同步，避免依赖工具猜测
Navicat 的定位是手动辅助型数据搬运工，不是变更管道。想让它“聪明”，就得提前在数据库里埋好钩子，再用脚本把它绑上钟表发条。
