Navicat 17的「结构同步」仅比对元数据，不支持时间戳过滤；需使用「数据同步」功能，手动配置WHERE条件（如updated_at >= NOW() - INTERVAL 1 HOUR）并勾选“仅同步满足条件的记录”。
Navicat 17 的「结构同步」不支持时间戳过滤，必须用「数据同步」
navicat 17 的「结构同步」（structure synchronization）只比对表定义、索引、约束等元数据，完全忽略数据内容和时间条件。你想要的「只同步最近一小时变更的数据」，必须进入 数据同步 功能（data synchronization），它才允许设置 where 条件过滤行。
在「数据同步」中配置时间戳 WHERE 条件的实操步骤
Navicat 不提供可视化时间函数下拉菜单，WHERE 条件需手动写 SQL 表达式，且必须严格匹配目标库的语法：
- 确认源表有可信赖的时间戳字段（如
updated_at、modified_time），类型为DATETIME或TIMESTAMP；不能是 VARCHAR 存储的时间字符串 - 在「数据同步」向导第 3 步「设置表映射」中，点击对应表右侧的
…按钮 → 选择设置筛选条件 - 输入类似以下 WHERE 表达式（注意适配你的数据库方言）：
updated_at >= NOW() - INTERVAL 1 HOUR
MySQL 可用；PostgreSQL 需改用：
updated_at >= NOW() - INTERVAL '1 hour'；SQL Server 则用：
updated_at >= DATEADD(HOUR, -1, GETDATE())
- 勾选
仅同步满足条件的记录（该选项默认关闭，漏选等于没过滤） - 若字段名含空格或关键字，用反引号（MySQL）或双引号（PostgreSQL）包裹，例如：
`last modified`
常见失败原因：时间字段时区、精度、NULL 值处理
即使 WHERE 语法正确，也常因这三点导致“看似没数据同步”：
-
updated_at字段值全为NULL：Navicat 过滤时会跳过这些行，不会报错但也不同步——检查源表是否真有更新时间写入逻辑 - 数据库服务器时区 ≠ 应用写入时区：比如应用用 UTC 写入
updated_at，但数据库设为Asia/Shanghai，NOW()返回的是东八区时间，对比会偏差 8 小时 - 字段精度问题：MySQL 5.6 之前
TIMESTAMP不支持毫秒，若应用写入带毫秒（如2024-05-20 14:30:22.123），入库后被截断，可能刚好卡在临界点外
增量同步不能只靠时间戳，还要考虑删除和主键冲突
时间戳过滤只解决「新增/修改」，但无法捕获「已删除的记录」。如果你需要双向一致，得额外处理：
- Navicat
数据同步默认是「源覆盖目标」，不会删目标库中源里没有的行——除非你主动勾选删除目标中不存在于源中的记录，但这依赖全量主键比对，不是增量逻辑 - 若源库软删除（如
is_deleted = 1），需把该条件也加进 WHERE，例如：updated_at >= NOW() - INTERVAL 1 HOUR AND is_deleted = 0
- 主键重复时（如目标库已有同 ID 记录），Navicat 默认执行
INSERT IGNORE或ON CONFLICT DO NOTHING（依数据库而定），不会自动 UPDATE——得在「高级选项」里切换为「更新匹配的记录」模式
真正可靠的增量同步，往往要结合 binlog/cdc 或专用工具；Navicat 的时间戳过滤适合低频、人工触发、且能接受小范围偏差的场景。
