navicat字段类型转换失败源于其不校验语义，仅直译sql导致目标库报“column type mismatch”；需通过日志获取sql、手动执行定位问题，并手动覆盖映射、禁用约束同步、修复大小写。
navicat 字段类型转换失败不是配置没点对，而是它根本不校验语义——你看到的“映射成功”，可能只是字符串拼接出来的 sql 被目标库当场拒收。
报错 “column type mismatch” 怎么快速定位真实原因
这个错误不是 Navicat 抛的，是目标数据库执行 CREATE TABLE 或 ALTER TABLE 时返回的。Navicat 只负责把源字段类型“直译”成目标方言，不验证是否合法。
- 打开 Navicat 日志窗口（底部状态栏右侧小图标），找报错前最后一条建表或加列的 SQL
- 复制整条 SQL，粘贴到目标库命令行（如
psql、mysql -e）里手动执行，看具体哪一列、什么类型被拒绝 - 重点比对：源字段定义（比如
NUMBER(10,2)）和 Navicat 生成的目标类型（比如只写了numeric没带精度，PostgreSQL 就会当成无限精度，而某些 ORM 驱动不认） - 常见陷阱：
TEXT被转成varchar(65535)（PostgreSQL 不支持该长度）、datetime2(7)同步到 MySQL 5.7（不支持微秒）
字段映射必须手动覆盖，不能信“自动匹配”
Navicat 没有全局类型映射表，所谓“映射”只发生在数据传输或结构同步向导中，且默认值极其保守（比如所有 NUMBER 统一映射为 numeric(1000,53)），这在生产环境基本不可用。
- 进入「数据传输」→「高级选项」→「字段映射」→ 点击对应列右侧的铅笔图标
- 对数字类型：明确选
int4（非integer）、int8（非bigint，避免解析歧义）、float8（非numeric(x,y)，除非真需要银行级精度） - 对时间类型：Oracle 的
DATE必须映射为timestamp without time zone，别选带with time zone的选项，否则迁移后时间偏移几小时 - 对字符串：
VARCHAR2(4000)直接改text，避开 UTF-8 四字节字符截断问题
外键、CHECK、索引导致同步中断怎么办
Navicat 默认按“先建表 → 再加约束 → 最后插数据”顺序执行，但异构库的约束语法差异大，它不会提前预警，只会静默失败或跳过。
- 同步前在「高级选项」里取消勾选「同步约束」，让表结构先跑通
- 建完表后，用目标库原生命令查真实约束：PostgreSQL 执行
SELECT indexdef FROM pg_indexes WHERE tablename = 'xxx'；MySQL 执行SHOW CREATE TABLE xxx - 对不兼容的约束（如 MySQL 的
FULLTEXT索引在 SQLite 不支持），必须手写兼容 DDL 替代，Navicat 不会提示 - 外键依赖顺序出错时，不要依赖「禁用外键检查」，而应先导出无约束的 DDL，再分批补约束
迁移后字段名大小写不一致引发 SQL 全挂
Oracle 默认大写标识符（"USER_ID"），PostgreSQL 默认小写（user_id）。Navicat 迁移完的字段全带双引号+大写，导致你原来写的 SELECT user_id FROM users 直接报错：column "user_id" does not exist。
- 别手动一个一个改，用这两条 SQL 批量修复：
SELECT 'ALTER TABLE "' || tablename || '" RENAME TO ' || lower(tablename) || ';' FROM pg_tables WHERE schemaname = 'public';SELECT 'ALTER TABLE ' || table_name || ' RENAME "' || column_name || '" TO ' || lower(column_name) || ';' FROM information_schema.columns WHERE table_schema = 'public';- 执行完后，在
psql里用\d 表名确认字段已变成小写、无双引号
最麻烦的不是类型映射本身，而是 Navicat 不暴露它的转换规则引擎——你永远不知道它下一步会把 bit 解释成 TINYINT(1) 还是 BOOLEAN，只能靠日志+手动执行+目标库验证三步闭环。一旦涉及时区、自增主键、domain 类型或扩展索引，就别指望向导能兜底。
