Navicat增量同步本质是手动构造WHERE条件实现的带过滤导出/导入，核心入口为Data Transfer和需启用Use WHERE的Data Sync；务必校准时区、谨慎选择created_at/id作为增量依据，并验证跨库权限与字段映射。
Navicat 增量同步本质是「带条件的数据导出 + 导入」
navicat 本身没有“增量同步”开关，它靠的是手动构造过滤条件，把新增或变更的记录筛出来再迁移。你看到的“同步”功能（tools → data sync）默认是全表比对，不加条件就是全量覆盖——这恰恰是多环境数据错乱的常见源头。
真正能控住增量的，只有两个入口：Data Transfer（导出+导入）和 Data Sync（需手动设 WHERE）。后者更安全，因为支持预览差异；前者更灵活，适合定时脚本化。
- 用
Data Sync时，必须点开每张表的Options→ 勾选Use WHERE condition，填类似created_at > '2024-06-01'或id > 10000 -
Data Transfer导出阶段就该加 WHERE，否则导出文件里混着旧数据，导入时直接覆盖目标库 - 时间字段务必确认时区一致：源库是 UTC、目标库是 CST？
created_at > DATE_SUB(NOW(), INTERVAL 1 HOUR)这类表达式在跨时区环境会漏数据
WHERE 条件怎么写才不丢数据｜timestamp vs auto-increment
选主键还是时间戳做增量依据，取决于你的业务写入模式。不是所有表都适合用 updated_at，也不是所有场景都能依赖 id。
- 用
id（自增主键）：适合写入顺序严格、无删除/重用 ID 的场景；但一旦有分表、归档、或中间插入历史数据，id > 10000就会跳过部分新增行 - 用
created_at：必须确保该字段不可为空、且应用层严格写入；如果允许 NULL 或批量补录，得额外加AND created_at IS NOT NULL - 用
updated_at：高风险！如果业务有定时任务更新全表状态，一次同步可能拉回上万条“伪新增” - 推荐组合：例如
WHERE created_at > '2024-06-01' AND id > 50000，双保险防边界漂移
Navicat Data Sync 的「忽略列」和「匹配字段」容易配反
在 Data Sync 的字段映射界面，有两个关键设置常被忽略：Match fields by name 和 Ignore columns。配错会导致“同步成功但数据没变”，或者“把 source 的 create_time 写进 target 的 update_time”。
- 勾选
Match fields by name后，Navicat 会自动按列名连线 —— 但如果两边表结构不一致（比如 target 多了个is_synced字段），它可能把status错连到is_synced -
Ignore columns不是“不读取”，而是“不参与比对也不写入”；比如想保留 target 的updated_at不被 source 覆盖，就必须把它加进 ignore 列表 - 务必点击
Preview：它显示的 SQL 是真实执行语句，检查 WHERE 是否生效、UPDATE SET 里有没有不该出现的字段
跨环境同步前必须验证连接用户权限
Navicat 看似连上了，不代表能执行同步操作。特别是从测试库同步到生产库时，权限不足不会报错，而是静默跳过某些表或字段。
- 目标库用户至少需要：
INSERT、UPDATE、SELECT（Data Sync会先查源表再比对）；如果用了TRUNCATE或DROP，还得有DROP权限（不建议启用） - MySQL 下，
SELECT权限不够细粒度时，Navicat 可能读不出information_schema表结构，导致字段映射失败，界面卡在“Loading…” - PostgreSQL 用户注意：
USAGEon schema +SELECTon table 缺一不可；否则Data Sync会提示permission denied for schema public
增量同步真正的复杂点不在 Navicat 操作，而在于你怎么定义“新增”——是按写入时间、状态标记、还是业务事件日志。工具只是执行者，逻辑错了，同步越快，污染越深。
