Navicat跨服务器数据同步必须使用“数据传输”功能，而非“数据同步”；需确保源库（SELECT权限）和目标库（CREATE/INSERT/DROP权限）连接可达、字符集兼容、字段映射正确，并通过自定义WHERE条件实现增量同步。
直接用 数据传输 功能替代备份还原，是异地、异构、增量同步场景下更稳的选择——它不生成中间文件、不依赖字符集完全一致、不强制锁表，失败时也更容易定位到具体字段或权限问题。
为什么“备份 → 拷贝 → 还原”在异地场景大概率失败
备份还原本质是回放一个全库快照，对环境一致性要求极高：
-
ERROR 1062: Duplicate entry常见于目标库已有数据，而还原默认会尝试插入重复主键，不是报错而是静默跳过或卡住 - 远程连接不稳定时，
正在还原…状态可能卡死数小时，Navicat 不提供中断重试机制 - 源库是
utf8mb4、目标库是utf8，含 emoji 的整行记录会被跳过，日志里无提示 - Oracle 备份文件（如 RMAN 或
.dmp）根本无法被 Navicat 的“还原”功能识别，点开就报Unsupported backup format
数据传输前必须手动确认的三件事
漏掉任一都会导致“看起来成功，实际丢数据”：
- 源库和目标库连接状态都必须是绿色已连接——不能一个连着、一个显示“断开”还点下一步
- 目标库中对应表必须已存在，且字段名、类型、主键定义需基本一致；例如源是
TEXT、目标是VARCHAR(50)，Navicat 默认跳过该列，不报错也不提醒 - 目标库用户必须有
INSERT、UPDATE、DELETE权限；只给SELECT会导致进度卡在“正在写入第 X 行”，日志只显示执行失败，不说明缺什么权限
关键参数必须进“高级模式”手动调
默认的“自动模式”只适合结构完全一致的同库同步，异地/异构场景必须改：
- 取消勾选
截断目标表，改用更新匹配记录 + 插入新记录：否则带自增主键或业务唯一索引的表会因主键冲突失败 - 勾选
删除目标表中不存在于源表的记录：不然旧数据残留，同步后看着像成功，实则是脏数据堆积 - 在
字段映射页逐个核对，尤其注意：created_at和updated_at别让源值覆盖目标最新时间；Oracle 的DATE要映射为 PostgreSQL 的timestamp without time zone，不是带时区那个 - 若源库字符集是
utf8mb4、目标是utf8，务必勾选忽略字符集转换错误，否则含 emoji 的记录整行丢弃
异构迁移（如 Oracle → PostgreSQL）必须改的三项
默认配置几乎必然失败，以下不调，90% 的表建不成功或数据溢出：
- 传输模式选
Transfer structure and data，不是“仅结构”也不是“仅数据” - 冲突处理勾选
Drop tables if exist：PostgreSQL 不支持CREATE OR REPLACE TABLE，不删旧表就报relation "xxx" already exists - 在
Edit Type Mapping中重点修正：NUMBER(10,0)→ 改为bigint（默认integer会溢出变负数）；VARCHAR2(4000)→ 保持text（别用character varying(4000)，避免 emoji 截断）
真正容易被忽略的，是字段映射那一页——它不弹窗提醒、不校验兼容性、不标记跳过的列，你得自己点开一行行看。很多“同步完成但数据不对”的问题，根源都在这里漏看了一个 DATE 映射成 date 而不是 timestamp。
