Navicat跨数据库传输时字段类型不兼容如何办

Navicat字段映射必须手动覆盖，默认值不可信；需在Data Transfer高级设置中禁用Auto-detect、逐列指定类型（如NUMBER→int4/int8/float8），并显式处理TIMESTAMP时区、字符集、大小写及约束等隐性差异。

字段映射必须手动覆盖，不能信默认值

Navicat 对跨库字段类型的“自动映射”本质是查内置硬编码表，不透明、不可调、边界 case 频繁翻车。比如 bit → Oracle 会直接报错 [Dtf 80120001: Source data type [bit] not supported；NUMBER(10,0) → PostgreSQL 默认转成 numeric(1000,53)，导致 Python 读取溢出、JOIN 性能暴跌。

实操建议：

1. 进「Data Transfer」→ 点「Advanced」→ 「Field Mapping」→ 必须逐列点开下拉菜单，手动选目标类型，别留默认值
2. 重点覆盖三类：NUMBER(10,0) → int4、NUMBER(*,0) → int8、NUMBER(x,y) → float8
3. 源为 bit 时，目标 Oracle 字段必须提前建为 NUMBER(1) 或 CHAR(1)，否则迁移中断
4. 禁用「Auto-detect data types」选项（在高级设置里取消勾选），避免 Navicat 自作主张二次推断

TIME 和 TIMESTAMP 时区处理失准，必须显式干预

TIMESTAMP 是跨库迁移中最容易静默出错的类型：MySQL 存 UTC、读本地时区；PostgreSQL 的 TIMESTAMP WITH TIME ZONE 行为不同；SQLite 根本没时区概念。Navicat 若不干预，常按字符串拼接，结果时间偏移几小时。

实操建议：

1. 源库连接串强制设时区：MySQL 加 ?serverTimezone=UTC，PostgreSQL 设 timezone='UTC'
2. Navicat 数据传输中勾选 Convert timestamp to UTC（如有），否则在「SQL Preprocessing」里写转换表达式，如 CONVERT_TZ(col, @@session.time_zone, '+00:00')
3. 目标字段统一选 TIMESTAMP WITHOUT TIME ZONE，别贪图带时区类型——它反而引发 session 解释歧义
4. 千万别用 Navicat 导出的 DDL 建目标表结构，它的 CREATE TABLE 常漏掉 WITH TIME ZONE 修饰符，应改用 pg_dump --schema-only 或手写 DDL

字符集与长度陷阱：utf8mb4 和 TEXT/VARCHAR 不是等价替换

看起来 VARCHAR(65535) 和 TEXT 都能存长文本，但 MySQL 内部处理天差地别：前者行内存储、受页大小限制；后者外存、影响索引和排序性能。同样，utf8mb4 下 emoji 占 4 字节，若目标库实际用的是 utf8（即 utf8mb3），VARCHAR(255) 实际只能存 63 个 emoji。

实操建议：

1. 迁移前统一目标库字符集：ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci
2. Navicat 连接目标库时，在「连接属性 → 高级」里勾选 Use Unicode，并手动选 utf8mb4（不是下拉默认的 utf8）
3. 别把源 VARCHAR(4000) 直接映射成目标 character varying(4000) —— 改成 text，PostgreSQL 对 text 更宽松，兼容 emoji 无截断
4. 用 SHOW CREATE TABLE 对比两边定义，确认 CHARACTER SET 和 COLLATE 完全一致，哪怕只是 utf8mb4_0900_as_cs vs utf8mb4_unicode_ci 都会触发 Illegal mix of collations

标识符大小写、主键、索引不会自动适配

Oracle 默认大写标识符（"USER_ID"），PostgreSQL 默认小写（user_id）。Navicat 迁完的表字段全带双引号+大写，你原来写的 SELECT user_id FROM users 直接报错 column "user_id" does not exist。自增主键、序列、索引更不会自动生成——Navicat 的「Data Transfer」只建空表。

实操建议：

1. 批量转小写字段名：SELECT 'ALTER TABLE ' || table_name || ' RENAME "' || column_name || '" TO ' || lower(column_name) || ';' FROM information_schema.columns WHERE table_schema = 'public';
2. Oracle 的 SEQUENCE + TRIGGER 逻辑，Navicat 不会还原。必须查 user_triggers，若存在 BEFORE INSERT 调用 nextval，MySQL 端就得补触发器或改应用层 ID 生成
3. 外键约束失败不是 Navicat bug，是它不解析依赖树。要么源库先执行 SET FOREIGN_KEY_CHECKS = 0，要么改用「Structure Synchronization」（仅限同构库）
4. 迁移后务必人工核对：主键是否生效、索引是否建立、NOT NULL 字段是否仍为非空、默认值是否保留

字段类型映射不是配置一次就能跑通的事，每一对源-目标组合都有其隐性规则，最危险的不是报错，而是静默截断、精度丢失、时区偏移——这些错误要到业务查询出错时才暴露。