不能直接“无损”迁移。Oracle和MySQL在数据类型、约束机制、默认行为上存在本质差异，Navicat的Convert Model是语义映射而非字节级复制，必须人工校验关键字段和逻辑。
不能直接“无损”迁移。Oracle 和 MySQL 在数据类型、约束机制、默认行为上存在本质差异，Navicat 的模型转换是「语义映射」而非「字节级复制」，必须人工校验关键字段和逻辑。
为什么 Convert Model 会丢失精度或报错
Navicat 的 Convert Model 功能依赖内置类型映射表，但 Oracle 的 NUMBER(10,2)、DATE、CLOB、SEQUENCE、SYSDATE 默认值等，在 MySQL 8.0 中没有一一对应项：
-
NUMBER→ 多数转为DECIMAL，但若源为NUMBER无精度声明，Navicat 可能误判为BIGINT，导致小数位丢失 -
DATE→ 转成DATETIME，但 Oracle 的DATE实际含时分秒，MySQL 的DATE类型不含时间，需手动改用DATETIME或TIMESTAMP -
CLOB→ 默认映射为TEXT，但若字段预期超 65535 字节，应主动改为MEDIUMTEXT或LONGTEXT -
CHECK约束 → MySQL 8.0.16+ 才支持，旧版目标库会静默丢弃，且 Navicat 不提示 -
DEFAULT SYSDATE→ 转成DEFAULT CURRENT_TIMESTAMP，但仅对第一列生效；多列默认时间需用触发器补全
执行 Convert Model 前必须做的三件事
跳过这步，后续同步到库时大概率建表失败或数据截断：
- 在 Navicat Data Modeler 中打开 Oracle 模型后，先右键每个表 →
Edit Table→ 检查所有NUMBER字段的Precision和Scale是否显式填写（空值会被误映射） - 确认目标 MySQL 连接已设为
MySQL 8.0版本（不是默认的MySQL 5.7），否则类型映射表会降级使用 - 关闭
Auto-adjust column length for VARCHAR选项（位于Tools → Options → Modeling → Physical Model），避免 Navicat 把VARCHAR2(200)自作主张缩成VARCHAR(191)（受 utf8mb4 索引限制影响）
转换后必须手动修正的典型字段
转换完成只是起点，以下字段几乎必改：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
ROWID类型字段 → 删除或替换为BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY，MySQL 无原生 rowid -
VARCHAR2(4000)→ 改为TEXT或MEDIUMTEXT（VARCHAR最大 65535 字节，但单行总长受限） -
CHAR(1 BYTE)→ 显式改为CHAR(1)并设置字符集为utf8mb4，否则可能被映射成TINYINT - 含
ON DELETE CASCADE的外键 → MySQL 8.0 支持，但需确认存储引擎为InnoDB（Navicat 默认可能设为MyISAM） - 主键名含双引号或大小写混合（如
"PK_USER_ID"）→ 删除引号并统一小写，MySQL 8.0 默认大小写敏感，且引号名在同步时易引发语法错误
同步模型到 MySQL 8.0 库前的最终检查点
别急着点 Synchronize to Database：
- 导出 DDL 预览（右键模型 →
Forward Engineer → SQL File），搜索CREATE TABLE块，确认无GENERATED ALWAYS AS（MySQL 不支持 Oracle 的虚拟列语法）、无ENABLE VALIDATE（MySQL 无此约束状态） - 检查
COLLATION：Oracle 默认USING_NLS_COMP，MySQL 应统一设为utf8mb4_0900_as_cs（区分大小写 + 口音） - 如果源模型含物化视图或数据库链接（
DBLINK），这些对象不会被转换，Navicat 也不会警告——需提前从模型中剔除
真正麻烦的从来不是点击「转换」那一下，而是 Oracle 的隐式行为（比如 NVL、DECODE、空字符串等于 NULL）在 MySQL 里没有等价体。模型能转过来，不等于业务逻辑能跑通；建议把核心表的 DDL 导出后，用 mysqld --sql-mode=STRICT_TRANS_TABLES 启动一个临时实例做语法验证。
