navicat数据同步无法自动保持环境一致，仅支持单次单向操作；需系统级调度+手动where增量控制+预处理sql+字符集统一+事后校验。
navicat 的数据同步功能不能自动保持开发与测试环境一致，它只执行一次性的、单向的比对与写入操作；真要“保持一致”，必须靠人工流程控制+外部调度+校验闭环，否则很快就会 drift。
同步任务必须手动触发，没有后台服务支撑
Navicat 自带的「自动运行」不是定时器，只是客户端前台活跃时按间隔轮询——关掉窗口、切到其他 App、锁屏后立即停摆。Windows/macOS/Linux 上真正稳定的方案只有两种：
- 用系统级调度调用
navicat.exe（Windows）或./navicat（macOS/Linux）命令行工具，传入导出的.ncx任务文件 - 改用支持服务化部署的工具，比如
pt-table-sync或云厂商的数据同步服务 - Windows 任务计划程序里务必勾选「不管用户是否登录都要运行」和「使用最高权限运行」，否则常见报错：
Failed to load job: Permission denied
Data Sync 的 WHERE 条件是增量控制唯一入口
Navicat 没有“增量同步”开关，所谓增量，全靠你手动填 WHERE 条件。不设条件就是全量覆盖，极易把测试库已有修改（如人工修正的配置项）直接冲掉。
- 在 Data Sync 向导中，逐张表点开
Options→ 勾选Use WHERE condition，填类似created_at > '2026-05-28'或id > 123456 - 时间字段必须确认时区一致：源库是 UTC、目标库是 CST？
NOW()表达式会失效，建议用固定时间戳或基于目标库SYS_DATE计算 - 避免单靠
updated_at：如果业务有定时全量更新状态的任务，一次同步可能拉回上万条“伪变更” - 推荐双条件保险：
WHERE created_at > '2026-05-28' AND id > 123456，防边界漂移
预处理 SQL 必须手动执行，同步本身不支持钩子
Navicat 数据同步没有 before/after 脚本入口，所有预处理（如清空缓存表、重置计数器、修正外键状态）都得你提前在目标库手动执行查询。
- 打开目标连接 → 右键数据库 →
查询，写好 SQL（例如TRUNCATE TABLE job_queue） - 右下角务必开启
自动提交，否则事务不生效 - 执行前核对顶部连接名——误在源库执行
TRUNCATE就是事故 - 别指望「忽略重复记录」能替代预处理：它只是跳过 INSERT 报错，不会清理已有脏数据
比对模式选错会导致静默覆盖或同步失败
Navicat 默认用「结构 + 数据」双比对，但多数场景只需要追加新记录。选错模式轻则极慢，重则把测试库人工维护的字段值（如 is_verified）直接回滚。
-
逐行比较：读取所有行主键+全部字段做哈希——10 万行以上明显卡顿，且要求表有主键或唯一索引 -
时间戳字段：需两张表都有同名updated_at且严格更新，老系统慎用 -
仅主键匹配：存在则跳过，不存在则插入——适合纯追加，但无法处理更新和删除 - 跨环境同步前，两个连接的「高级」设置里
Character set必须一致（如都为utf8mb4），否则中文变问号、INSERT IGNORE转成普通INSERT导致中断
最易被忽略的一点：Navicat 同步成功 ≠ 数据一致。它不校验应用语义，也不感知业务约束；一次成功的同步可能让测试库外键失效、时间字段全变成零值、或 JSON 字段被截断成字符串——这些都得靠你额外用 SQL 手动查 COUNT(*)、MAX(CHAR_LENGTH())、SHOW CREATE TABLE 来兜底。
