数据同步的本质是保障多系统间数据状态一致，而非简单搬运；它依赖主键识别变更并执行精准增删改，需先结构同步、再校验主键、最后增量同步，否则易致冲突或丢数据。
别用 数据同步 去干 数据传输 的活，也别指望 数据传输 能解决多环境间的数据一致性问题——这是最常踩的坑，直接导致主键冲突、重复插入或丢数据。
数据传输（Data Transfer）适合一次性全量搬运
它本质是“导出+导入”：读取源表全部数据，生成 INSERT 语句（或直接写入），目标表存在就先清空再写入。不比对、不识别变更、不依赖主键。
- 适用场景：
初始化新库、备份还原、跨数据库类型迁移（比如 MySQL → PostgreSQL） - 风险点：目标表原有数据会被覆盖；若目标表有自增主键，
TRUNCATE后重置起始值，可能引发后续插入冲突 - 参数注意：
忽略错误开关要慎开——比如遇到重复主键时跳过，表面成功实则漏数据 - 性能影响：大数据量时更快，因为无比对开销；但网络/磁盘 IO 是瓶颈，不是 CPU
数据同步（Data Synchronization）依赖主键做差异识别
它先查源和目标的主键/唯一键集合，再逐行比对字段值，最终只生成真正需要的 INSERT/UPDATE/DELETE 语句。默认开启事务，支持预览。
- 适用场景：
开发库→测试库日常同步、生产库→灾备库增量更新、多租户数据分发 - 前提条件：源表和目标表必须有相同主键或唯一键；字段名、类型、长度最好一致，否则映射易出错
- 常见错误：
ERROR: duplicate key violates unique constraint——通常是因为目标表多了本地插入的数据，而同步没设“仅同步变更行”，结果强行 INSERT 已存在主键 - Navicat 17 的
增量识别和并行通道确实提速，但前提是目标库支持批量 UPSERT（如 MySQL 的ON DUPLICATE KEY UPDATE），否则仍会退化为单行执行
结构同步（Structure Synchronization）只动 DDL，不动数据
它对比的是表定义、索引、外键、视图等元信息，生成 ALTER/CREATE/DROP 语句。和前两者完全正交——你完全可以先用 结构同步 对齐表结构，再用 数据同步 对齐内容。
- 典型误用：在目标库已有数据的情况下，直接用
结构同步加字段，却忘了目标表可能因新增NOT NULL字段而同步失败 - 安全做法：勾选
生成脚本而非直接执行，人工检查ALTER TABLE ... ADD COLUMN是否带DEFAULT或允许NULL - 注意兼容性：
MySQL和PostgreSQL对同一 DDL 的语法容忍度不同，跨库结构同步需手动调整生成脚本
真正容易被忽略的是三者之间的协作顺序：先 结构同步 确保表定义一致，再确认主键可用，最后才跑 数据同步；如果跳过结构校验直接同步，Navicat 可能静默跳过某些字段映射，导致目标数据“看起来一样，实际缺字段”。
