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 性能暴跌。
实操建议：
- 进「Data Transfer」→ 点「Advanced」→ 「Field Mapping」→ 必须逐列点开下拉菜单，手动选目标类型，别留默认值
- 重点覆盖三类：
NUMBER(10,0)→int4、NUMBER(*,0)→int8、NUMBER(x,y)→float8 - 源为
bit时，目标 Oracle 字段必须提前建为NUMBER(1)或CHAR(1)，否则迁移中断 - 禁用「Auto-detect data types」选项（在高级设置里取消勾选），避免 Navicat 自作主张二次推断
TIME 和 TIMESTAMP 时区处理失准，必须显式干预
TIMESTAMP 是跨库迁移中最容易静默出错的类型：MySQL 存 UTC、读本地时区；PostgreSQL 的 TIMESTAMP WITH TIME ZONE 行为不同；SQLite 根本没时区概念。Navicat 若不干预，常按字符串拼接，结果时间偏移几小时。
实操建议：
- 源库连接串强制设时区：MySQL 加
?serverTimezone=UTC，PostgreSQL 设timezone='UTC' - Navicat 数据传输中勾选
Convert timestamp to UTC（如有），否则在「SQL Preprocessing」里写转换表达式，如CONVERT_TZ(col, @@session.time_zone, '+00:00') - 目标字段统一选
TIMESTAMP WITHOUT TIME ZONE，别贪图带时区类型——它反而引发 session 解释歧义 - 千万别用 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。
实操建议：
- 迁移前统一目标库字符集：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci - Navicat 连接目标库时，在「连接属性 → 高级」里勾选
Use Unicode，并手动选utf8mb4（不是下拉默认的utf8） - 别把源
VARCHAR(4000)直接映射成目标character varying(4000)—— 改成text，PostgreSQL 对text更宽松，兼容 emoji 无截断 - 用
SHOW CREATE TABLE对比两边定义，确认CHARACTER SET和COLLATE完全一致，哪怕只是utf8mb4_0900_as_csvsutf8mb4_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」只建空表。
实操建议：
- 批量转小写字段名：
SELECT 'ALTER TABLE ' || table_name || ' RENAME "' || column_name || '" TO ' || lower(column_name) || ';' FROM information_schema.columns WHERE table_schema = 'public'; - Oracle 的
SEQUENCE+TRIGGER逻辑，Navicat 不会还原。必须查user_triggers，若存在BEFORE INSERT调用nextval，MySQL 端就得补触发器或改应用层 ID 生成 - 外键约束失败不是 Navicat bug，是它不解析依赖树。要么源库先执行
SET FOREIGN_KEY_CHECKS = 0，要么改用「Structure Synchronization」（仅限同构库） - 迁移后务必人工核对：主键是否生效、索引是否建立、
NOT NULL字段是否仍为非空、默认值是否保留
