oracle的number主键迁至mysql后变为decimal，须手动改为int/bigint并加auto_increment和primary key；oracle date含时分秒，navicat默认映为mysql date会丢精度，应改用datetime或timestamp。
oracle的number字段迁移到mysql后变成decimal，怎么改为主键+自增？
navicat不会自动识别oracle的number是否用作主键或是否需自增，一律转为decimal(38,0)——这导致mysql无法设auto_increment，插入会报错。
迁移前无法批量修正，必须在MySQL目标库中手动调整：
- 先确认原Oracle表主键字段（如
FID），检查Navicat生成的目标表结构是否为DECIMAL - 执行
ALTER TABLE `t_xx` MODIFY `FID` INT UNSIGNED NOT NULL AUTO_INCREMENT FIRST; - 再加主键：
ALTER TABLE `t_xx` ADD PRIMARY KEY (`FID`); - 如果原值超出
INT范围（>2147483647），改用BIGINT，但注意BIGINT UNSIGNED AUTO_INCREMENT在MySQL 5.7+才完全支持
Oracle的DATE类型直接迁移到MySQL会丢时间精度，为什么？
Oracle的DATE实际包含年月日时分秒（精度到秒），而MySQL的DATE只存日期部分。Navicat默认把DATE映射为DATE，导致1999-01-01 14:30:22变成1999-01-01。
正确做法是迁移前在Oracle侧统一升级字段类型：
- 运行PL/SQL脚本，将所有
DATE列改为TIMESTAMP（推荐TIMESTAMP(6)） - Navicat就能将其映射为MySQL的
DATETIME或TIMESTAMP，保留完整时间 - 若已迁移失败，只能导出SQL再全局替换
DATE为DATETIME，重新导入
迁移时遇到[Err] [Dtf] 2006 - MySQL server has gone away怎么办？
这不是Navicat问题，是MySQL服务端中断了大包传输。常见于含CLOB/BLOB字段的表，或单条INSERT超长。
必须调大MySQL服务端参数，仅改客户端无用：
- 编辑
my.ini（Windows）或my.cnf（Linux），增加或修改： -
max_allowed_packet = 512M（建议从64M起步，逐步加大） -
wait_timeout = 28800（避免连接空闲超时） - 重启MySQL服务，再重试迁移
- 若仍失败，可在Navicat“数据传输”→“高级”里勾选“遇到错误继续”，先过完结构，再单独处理大字段表
Oracle的VARCHAR2(4000)在MySQL里变成了TEXT，还能建索引吗？
能，但有限制：MySQL对TEXT字段建索引必须指定前缀长度，比如INDEX(`content`(255))。而Oracle的VARCHAR2可全文索引。
迁移后若需高效查询，建议主动降级字段类型：
- 若实际内容普遍VARCHAR(255)并建全文索引
- 若必须保留长文本，且常按前N字符查询，建前缀索引，如
INDEX(`desc`(191))（注意InnoDB默认索引长度上限767字节，utf8mb4下最多191字符） - Navicat不提示该限制，等建索引时报
Specified key was too long才暴露问题
关键点在于：Navicat的类型映射是静态规则表驱动的，它不读取业务语义。主键、索引、精度需求这些逻辑，全靠人工在迁移前后补位。别信“一键完成”。
