navicat 数据同步的时间过滤条件必须在「表映射」步骤中每张表的「设置筛选条件」里填写并勾选「仅同步满足条件的记录」，否则即使选择增量模式也会全量同步；where 语句需严格匹配目标库 sql 方言，且时间字段类型、时区、精度等均影响实际效果。
where 条件必须写在「表映射」页的过滤框里
navicat 不会在「高级选项」或「同步选项」里读取时间条件，真正起作用的只有 表映射 步骤中每张表右侧的 … 按钮 → 「设置筛选条件」里填的 sql 表达式。漏掉这一步，哪怕你选了「插入和更新」也还是全量同步。
常见错误现象：同步后目标库多了几千条旧数据、日志表重复插入、预览显示 Insert 行数远超预期——基本都是没填这个过滤框，或者填错位置。
- 入口路径：数据同步向导第 3 步 → 找到你要同步的表 → 点右侧
…→ 选「设置筛选条件」 - 必须勾选「仅同步满足条件的记录」，该选项默认关闭，不勾等于白写
- 字段名含空格或关键字时，MySQL 用反引号包裹，如
`last modified`；PostgreSQL 用双引号，如"updated at"
不同数据库的时间表达式写法不能混用
Navicat 不做语法转换，你写的 WHERE 必须严格匹配目标数据库的 SQL 方言。同一个 NOW() - INTERVAL 1 DAY 在 MySQL 可用，但在 PostgreSQL 或 SQL Server 会直接报错。
实操建议：先在目标库的查询窗口里粘贴测试，确认能返回最近三天的数据，再复制进 Navicat 过滤框。
- MySQL：
updated_at >= DATE_SUB(NOW(), INTERVAL 3 DAY) - PostgreSQL：
updated_at >= NOW() - INTERVAL '3 days' - SQL Server：
updated_at >= DATEADD(day, -3, GETDATE()) - Oracle：
updated_at >= SYSDATE - 3
时间字段本身不可靠时，同步会静默失效
即使 WHERE 语法完全正确，也可能“看起来没同步任何数据”——不是 Navicat 坏了，而是时间字段值或时区不匹配导致条件永远不成立。
典型表现：预览结果显示 0 行 Insert/Update，但源表明明有三天内变更的记录。
-
updated_at字段全为NULL：Navicat 过滤时跳过这些行，不报错也不同步 - 应用写入用 UTC，数据库服务器时区设为
Asia/Shanghai：NOW() 返回东八区时间，对比时偏差 8 小时 - 字段类型是
VARCHAR存时间字符串：无法参与日期运算，WHERE 条件恒为 false - MySQL 5.6 之前
TIMESTAMP无毫秒精度：若应用写入2026-06-08 14:22:33.892，入库后变成2026-06-08 14:22:33，刚好卡在边界外
「仅插入」模式下仍需配合时间过滤，否则仍是全表扫描
选「仅插入」不会自动限范围，它只影响冲突行为（遇到主键重复就跳过），但 Navicat 仍会把整张源表拉出来逐行比对主键是否存在。没加 WHERE，就是全表 IO + 全表锁风险。
真正控制“只拿最近三天”的，还是那个过滤条件。不加，哪怕你只想要新增订单，Navicat 也会去比对上百万条历史订单的主键。
- 推荐用
created_at >= '2026-06-08 00:00:00'这类静态时间字符串，GUI 不支持NOW()等运行时函数 - 时间字符串务必带秒，避免跨分钟漏数据，比如写成
'2026-06-08 00:00:00'，别写'2026-06-08' - 如果用
id > 123456做锚点，得确保该字段单调递增且无归档重用，否则中间补录的数据会被跳过
时间戳过滤只是增量同步的第一层，它不处理删除、不保证双向一致、也不解决主键不匹配时的定位失败——这些都得靠你手动核对映射、关掉危险选项、并每次同步后更新过滤值。
