Navicat跨平台数据对比需主键/唯一索引字段名、类型、语义完全一致，因其底层依赖该键行级匹配，不支持自动字段映射或类型智能转换，且同步脚本生成不校验目标库语法兼容性与约束条件。
navicat 的“数据对比”功能能直接比对跨平台数据库（如 mysql ↔ postgresql、mysql ↔ sql server）的表级记录差异，但必须满足一个前提：两库中对应表的主键或唯一索引字段名、类型、逻辑语义完全一致；否则对比结果不可靠，甚至无法启动。
为什么“数据对比”不支持任意跨平台表比对？
Navicat 底层依赖主键/唯一键做行级匹配。如果源库用 id 作主键，目标库用 user_id，即使值相同，Navicat 也无法自动关联两行——它不会做字段名映射或业务逻辑推断。
- MySQL 和 PostgreSQL 都支持
serial/INT PRIMARY KEY AUTO_INCREMENT，但 Navicat 不会把serial自动等价为自增整型，需人工确认类型是否可兼容（如INTEGERvsBIGINT） - SQL Server 的
uniqueidentifier和 MySQL 的CHAR(36)看似可比，但 Navicat 默认不启用 UUID 格式标准化，比对时可能因大小写或连字符位置误判为不一致 - Oracle 的
ROWID是物理地址，不能用于跨库比对；若表无显式主键，Navicat 会拒绝进入对比流程，报错No primary key or unique index found
如何配置才能让跨平台数据对比真正跑起来？
关键在“连接参数”和“对比设置”两个地方，不是点几下就能跳过：
- 在目标库连接属性中，勾选
Use Unicode（尤其对 SQL Server / Oracle），避免中文字段因字符集解析失败导致整行比对跳过 - 进入“工具 → 数据对比”后，手动指定“匹配字段”：点击对应表右侧的齿轮图标，在弹窗中把源库的
id和目标库的user_id显式绑定——这是跨名比对的唯一合法路径 - 若字段类型存在隐式转换风险（如 MySQL
DATETIMEvs PostgreSQLTIMESTAMP WITHOUT TIME ZONE），在“高级选项”里取消勾选Compare timestamp with timezone，否则时区偏移会被当作数据差异 - 对于含 JSON 字段的表（MySQL 5.7+ / PostgreSQL / SQL Server 2016+），Navicat 默认按字符串比对；若需忽略空格或键序差异，必须提前在两边数据库中统一用
JSON_NORMALIZE()或jsonb_strip_nulls()处理后再比对
比对结果出来后，同步脚本为什么常出错？
Navicat 生成的 DML 同步语句（INSERT/UPDATE/DELETE）是“按目标库语法生成”的，但跨平台时容易卡在三个地方：
- MySQL 的
ON DUPLICATE KEY UPDATE在 PostgreSQL 中不生效，Navicat 却仍会生成该语法，执行时报错syntax error at or near "ON" - SQL Server 的
MERGE语句要求目标表必须有主键且不能有触发器，而 Navicat 不校验该约束，直接生成后运行失败 - 当某行在源库为 NULL、目标库为 ''（空字符串）时，Navicat 默认认为二者不同，但生成的 UPDATE 语句可能因目标库字段设了
NOT NULL DEFAULT ''而报错NULL value not allowed - 最隐蔽的是时间精度：MySQL 默认秒级 DATETIME，PostgreSQL 可存微秒；Navicat 比对时若未开启“忽略毫秒”，会把
'2024-01-01 12:00:00'和'2024-01-01 12:00:00.000000'当作差异，但生成的同步语句又无法补全精度，导致反复比对始终不一致
跨平台数据比对不是“点比较→点同步”就完事的事。主键对齐、类型显式声明、时间精度约定、空值语义统一——这些细节没在比对前确认清楚，后面每一步都在放大误差。真正省时间的地方，从来不在点击“开始”那一刻，而在打开“结构同步”窗口之前那五分钟检查。
