Navicat Premium 16支持MySQL到Oracle跨库同步，但需手动干预字段类型、主键策略、空值约束和长度限制四类问题；常见卡点是“正在创建表”或ORA-00904错误，因Oracle对标识符长度（≤30）、大小写敏感、数据类型兼容性有硬性要求。
Navicat Premium 16 支持 MySQL 到 Oracle 的跨库同步，但不是“一键自动适配”，必须手动干预关键环节才能跑通。直接点说：能同步，但字段类型、主键策略、空值约束、长度限制这四类问题大概率会中断任务。
为什么 数据传输 会卡在“正在创建表”或报 ORA-00904 错误
这是最常遇到的阻塞点。navicat 默认按源库（mysql）字段定义生成 ddl，但 oracle 对标识符长度（≤30 字符）、大小写敏感（双引号包裹才保留小写）、数据类型兼容性（如 tinyint → number(3)）有硬性要求。
常见错误现象：ORA-00904: "id" invalid identifier 或 ORA-00972: identifier is too long
- 确保 Oracle 目标用户已预建空 schema（如
KCDA），且有CREATE TABLE权限 - 在
数据传输窗口的【高级】页勾选转换对象名为大写—— 避免大小写和双引号引发的解析失败 - 取消勾选
外键限制：Oracle 在单表插入时若存在未建的外键依赖，会直接报错；先传数据，再用 SQL 补外键 - 如果源表字段名含下划线或数字开头（如
2nd_contact），Navicat 可能生成非法 Oracle 标识符，需提前在 MySQL 中重命名或手动改目标 DDL
varchar 和 int 类型映射后为啥变成 VARCHAR2(255) 和 NUMBER？
Navicat 的类型映射是保守策略：不读取原始精度，只做宽泛等价转换。比如 MySQL 的 VARCHAR(100) 会被转成 Oracle 的 VARCHAR2(255)，INT 统一映射为 NUMBER(10) —— 这虽能存下数据，但可能破坏索引选择性或违反业务长度约束。
- 不要依赖自动映射结果做生产部署；迁移完成后，必须用
SELECT data_type, data_length FROM all_tab_columns WHERE table_name = 'XXX'核对实际列定义 - 若需精确控制，建议先导出 MySQL 的建表语句，用文本替换（如
int(11)→NUMBER(11)，varchar(50)→VARCHAR2(50)），在 Oracle 中手动执行 DDL，再用 Navicat 只同步数据（勾选仅数据） - 注意
TIMESTAMP类型：MySQL 的TIMESTAMP默认带时区，Oracle 的TIMESTAMP不带，容易丢精度；建议统一用TIMESTAMP WITH TIME ZONE并在同步前确认时区设置
如何避免 NULL 值导致同步中断？
Oracle 对 NOT NULL 字段的校验比 MySQL 更严格。当 MySQL 某列为 INT NOT NULL DEFAULT 0，但实际存在 NULL 值（因历史数据或 MyISAM 引擎宽松校验），Navicat 同步时会直接报 ORA-01400: cannot insert NULL into ...。
- 同步前，在 MySQL 执行
SELECT COUNT(*) FROM table_name WHERE column_name IS NULL，定位空值字段 - 要么清洗数据（
UPDATE table_name SET column_name = 0 WHERE column_name IS NULL），要么临时修改 Oracle 目标列允许NULL，同步完成后再加约束 - 在 Navicat
数据传输的【高级】页勾选遇到错误继续—— 仅适用于调试阶段；生产环境务必关闭，否则静默丢失记录
增量同步只能靠 时间戳字段 + 手动过滤实现
Navicat 的 数据传输 功能本身不提供“上次同步时间点”记忆机制，所谓“增量”需人工构造条件。
- 若表有
update_time字段，可在【表选项】中点击该表右侧的…，填入WHERE update_time > TO_DATE('2026-06-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS') - 不能用 MySQL 的
NOW()或CURRENT_TIMESTAMP，必须用 Oracle 可识别的固定时间字面量或SYSDATE - 没有更新时间字段的表，无法安全做增量；要么全量重刷，要么在 MySQL 侧加触发器记录变更日志表，再单独同步该日志表
