Navicat跨库同步失败主因是类型系统差异，需手动映射字段（如TINYINT→BOOLEAN、DATETIME→TIMESTAMP WITH TIME ZONE）、跳过错误记录、预建表结构并设NULL允许、校验行数时用MD5+ORDER BY防静默丢数据。
同步时提示“Data type mismatch”或字段映射失败
navicat premium 跨库同步（比如 mysql → postgresql 或 sql server → mysql）失败，多数是因为源库和目标库的类型系统不一致，int 和 integer 看似一样，但 navicat 不会自动做跨方言映射；tinyint(1) 在 mysql 里常被当布尔用，但在 postgresql 里没有对应原生类型，直接同步就会卡在字段校验阶段。
实操建议：
- 同步前先手动打开「高级选项」→「字段映射」，逐个检查报错字段，把
TINYINT映射为BOOLEAN（PostgreSQL）或TINYINT（SQL Server），别依赖自动推断 - 对
TEXT/MEDIUMTEXT类型，MySQL 目标可保留，但 PostgreSQL 目标必须映射为TEXT（它没有MEDIUMTEXT） - 时间类型尤其危险：
DATETIME（MySQL）和timestamp without time zone（PostgreSQL）精度、时区行为不同，建议统一映射为TIMESTAMP WITH TIME ZONE并确认源库时区设置
同步任务保存后执行时报错 “Cannot convert value … to target type”
这通常不是建表阶段的问题，而是数据迁移时运行时转换失败。Navicat 默认启用严格类型校验，遇到空字符串插入 INT 字段、NULL 插入 NOT NULL 列、或超长字符串写入 VARCHAR(50) 就会中断。
实操建议：
- 勾选「高级选项」→「跳过错误记录」，避免单条脏数据阻塞全量同步（但要配合日志排查）
- 提前在目标库手动建好表结构，并把字段设为
NULL允许（除非业务强约束），Navicat 的自动建表逻辑对跨库兼容性支持很弱 - 对含默认值的字段（如
created_at DEFAULT CURRENT_TIMESTAMP），MySQL 和 PostgreSQL 的默认值语法不互通，务必在目标库预置好默认表达式，不要让 Navicat 自动生成
Oracle → MySQL 同步时 NUMBER 映射成 DECIMAL 还是 BIGINT？
NUMBER(p,s) 是 Oracle 的通用数值类型，p=38, s=0 时等价于 128 位整数，远超 MySQL 的 BIGINT（64 位）。Navicat 默认映射为 DECIMAL(38,0)，看起来安全，但实际会拖慢查询、索引效率，且部分 ORM 框架不识别大精度 DECIMAL。
实操建议：
- 先查源表该字段的实际取值范围：
SELECT MIN(col), MAX(col) FROM table_name，如果最大值（即 <code>BIGINT上限），就手动映射为BIGINT - 若含小数（s > 0），且业务允许精度损失，可映射为
DOUBLE；否则坚持用DECIMAL(p,s)，但需确认 MySQL 版本 ≥ 8.0.17（修复了部分 DECIMAL 计算 bug） - 千万避开 Navicat 的「自动映射」按钮——它对
NUMBER统一转DECIMAL(38,0)，极易引发后续性能问题
同步完成后数据行数对不上，但没报错
这是最隐蔽的问题：Navicat 的「验证行数」功能只比对 COUNT(*)，而跨库事务隔离级别、MVCC 实现差异可能导致快照不一致；更常见的是，MySQL 的 utf8mb4 字符集下某些 emoji 占 4 字节，PostgreSQL 若用 UTF8 编码但列定义为 CHARACTER VARYING(10)，可能因截断导致隐式丢数据，却不会报错。
实操建议：
- 同步后立刻执行校验查询，例如：
SELECT MD5(GROUP_CONCAT(CONCAT_WS('|', col1, col2))) FROM table_name（注意排序一致性，加ORDER BY id） - 对文本字段，额外比对
LENGTH()和OCTET_LENGTH()（PostgreSQL）或CHAR_LENGTH()（MySQL），确认是否发生静默截断 - Navicat 的日志级别默认太低，需在「工具」→「选项」→「日志」中启用「详细模式」，否则丢失关键转换警告（如 “truncated value for column…”）
