navicat数据同步的where条件必须填在「表映射」页的筛选框里，而非高级或同步选项；需勾选“仅同步满足条件的记录”并正确书写sql，注意字段名引号、函数兼容性、时区及数据类型匹配。
where条件必须填在「表映射」页的筛选框里
navicat 数据同步的 where 条件不起作用，90% 是因为填错了位置。它**不在「高级选项」或「同步选项」里**，而是在同步向导第 3 步「表映射」中：找到目标表 → 点右侧 … 按钮 → 选「设置筛选条件」→ 勾选「仅同步满足条件的记录」→ 在下方输入框写 sql。
常见错误现象：预览 显示 Insert 行数远超预期、目标库出现大量旧数据、日志表重复插入——基本都是漏勾这个选项，或者压根没点开 … 填条件。
- 不勾选「仅同步满足条件的记录」，哪怕你写了
updated_at > '2026-07-24'也无效 - 字段名含空格或关键字时，MySQL 必须用反引号，如
`updated at`；PostgreSQL 用双引号，如"updated_at" - 同一个条件
NOW() - INTERVAL 3 DAY在 MySQL 可用，但在 PostgreSQL 或 SQL Server 会直接报错ERROR: syntax error
时间字段类型和时区不匹配会导致条件静默失效
语法完全正确，但 预览 显示 0 行？不是 Navicat 坏了，而是时间字段本身不可靠。
典型表现：源表明明有三天内变更的记录，同步却一条都不拉。原因可能是：
- 应用写入用 UTC，数据库服务器时区是
Asia/Shanghai：SQL 中NOW()返回东八区时间，对比时偏差 8 小时 - 时间字段是
VARCHAR存的字符串（如'2026-07-25 10:30:00'）：无法参与日期运算，WHERE条件恒为 false - MySQL 5.6 之前
TIMESTAMP无毫秒精度：应用写入'2026-07-25 14:22:33.892'，入库后截断为'2026-07-25 14:22:33'，刚好卡在>=边界外
实操建议：先在目标库查询窗口执行你写的条件，确认 SELECT COUNT(*) FROM 表名 WHERE … 返回预期行数，再复制进 Navicat。
「仅插入」模式仍需配合 WHERE 过滤
选「仅插入」不会自动限范围，它只影响冲突行为（遇到主键重复就跳过），但 Navicat 仍会把整张源表拉出来逐行比对主键。没加 WHERE，就是全表扫描，耗时长还容易锁表。
真正控制“只拉新增”的，是你在表映射里填的语句，比如：
-
created_at > '2026-07-24 00:00:00'（注意单引号不能少） -
id > 98765（适用于自增主键、无删除/重用 ID 的场景） -
created_at > '2026-07-24' AND id > 98765（双条件防边界漂移）
如果源表用 UUID 当主键，而目标表是自增 id，仅插入 会失效——Navicat 根本找不到匹配依据。
导出功能不支持直接填 WHERE，必须走「查询结果导出」
Navicat 16 的标准导出向导不解析 WHERE 子句。你在「表名」栏输 orders WHERE order_date >= '2026-07-01'，会直接报错 Unknown table 'orders WHERE ...'。
正确做法是：
- 新建查询 → 写完整语句，例如：
SELECT * FROM orders WHERE order_date >= '2026-07-01' AND order_date - 点击 ▶ 执行 → 确认结果集正确（注意右下角是否启用了「只读取前 N 行」）
- 保存该查询（命名为
export_orders_202607）→ 导出时在数据源选择「查询」节点，而不是「表」节点 - 日期字段是
DATETIME类型时，避免用等值= '2026-07-01'，改用范围>= '2026-07-01' AND
最容易被忽略的是：导出向导里的 Limit rows 默认可能设为 0 或极小值，导致文件只有表头没数据——务必在「选项」页里改成 0。
