Navicat Premium 16的跨库类型映射是基于厂商文档的静态规则匹配，不读取源字段实际精度、约束或业务语义，故默认映射常出错，如Oracle VARCHAR2(100)→MySQL VARCHAR(255)、NUMBER→DECIMAL(38,0)、DATE→DATE（丢时分秒）；需在数据传输向导“选项→类型映射”中手动调整，并迁移后验证实际列定义、主键属性及时效性。

Navicat Premium 16 不会自动“智能”推断业务语义，所谓“智能映射”本质是可配置的静态规则匹配，不是 AI 推理。必须手动干预才能避免 VARCHAR2(4000) → TEXT、NUMBER → DECIMAL 这类破坏性转换。

为什么默认映射经常出错？

Navicat 的跨库类型映射基于厂商文档的宽泛等价表，不读取源库字段的实际精度、约束或用途：

• Oracle VARCHAR2(100) → MySQL VARCHAR(255)（而非原长），因为 Navicat 不解析括号内数值
• Oracle NUMBER 主键 → MySQL DECIMAL(38,0)（无法设 AUTO_INCREMENT，插入直接报错）
• Oracle DATE → MySQL DATE（丢时分秒，因 Oracle DATE 实际含时间精度）
• MySQL JSON 字段导入时被识别为 TEXT，但 Navicat 不会自动加 GENERATED 列或检查有效性

怎么在数据传输向导里改映射规则？

关键路径：数据传输 → 选源/目标连接 → 选项 标签页 → 类型映射 按钮。这里能覆盖绝大多数问题：

DrugBank 数据库

访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-

下载

• Oracle → MySQL：把 NUMBER 映射改为 BIGINT 或 INT（若确认无小数且值域安全）
• Oracle → MySQL：把 DATE 映射改为 DATETIME 或 TIMESTAMP（保留时间部分）
• MySQL → Oracle：把 VARCHAR 映射改为 VARCHAR2（避免后续 PL/SQL 报错）
• 禁用“自动调整长度”选项：否则 VARCHAR2(50) 可能被扩成 VARCHAR2(255)

迁移后必须验证的三件事

自动映射只负责建表，不校验业务合理性。以下检查不能跳过：

• 执行 SELECT data_type, data_length, data_precision FROM all_tab_columns WHERE table_name = 'YOUR_TABLE'（Oracle）或 SHOW COLUMNS FROM your_table（MySQL），确认实际生成的类型和长度
• 检查主键字段是否真成了 INT NOT NULL AUTO_INCREMENT，而不是残留的 DECIMAL
• 对含时间字段的表，查几条记录看 1999-01-01 14:30:22 是否变成 1999-01-01 00:00:00 —— 若是，说明 DATE 映射没生效，得重跑或手动 ALTER

最常被忽略的是：Navicat 的映射规则只影响新建表结构，对已存在的目标表无效。如果第一次迁移失败后直接点“重新运行”，它不会覆盖旧表定义，而是跳过建表步骤——此时看到的仍是错误类型。