Navicat配置异构表字段类型映射的详细步骤是什么

Navicat无全局字段类型映射配置，仅在数据迁移和结构同步向导中临时设置；需手动指定源目标类型对应关系，如MySQL TIMESTAMP→PostgreSQL timestamp with time zone，并注意时区、JSON降级及映射不保存等限制。

Navicat里改字段类型映射，不是在“表设计”里点点就完事

navicat本身不提供全局异构数据库（比如 mysql ↔ postgresql）之间的字段类型自动映射配置。所谓“字段类型映射”，只存在于两个特定场景：数据迁移（data transfer）和结构同步（structure synchronization）。你找不到一个叫“类型映射设置”的独立面板——它藏在向导每一步的细节里，且仅对当前任务生效。

常见错误现象：TEXT 被转成 character varying(255)、TIMESTAMP 丢掉时区、JSON 字段变成 text 后无法被目标库识别为 JSON 类型。这些都不是 Navicat “映射错了”，而是你没在迁移/同步前主动指定规则。

迁移时，在 Data Transfer 向导第 3 步（“Options”）中点击 Advanced → 勾选 Use custom type mapping，再点 Edit Mapping
同步时，在 Structure Synchronization 向导最后一步（“Review Options”）点 Options → 同样进 Edit Mapping
映射表里左侧是源库类型（如 mediumtext），右侧填目标库对应类型（如 text），支持带长度或修饰符，例如 varchar(500)

MySQL转PostgreSQL时，datetime/timestamp必须手动处理时区

MySQL 的 DATETIME 无时区，TIMESTAMP 默认存 UTC；PostgreSQL 的 timestamp without time zone 和 timestamp with time zone 行为完全不同。Navicat 默认把两者都映射成 timestamp without time zone，结果就是时间值偏移、查询错乱。

使用场景：你从 MySQL 迁移订单表，其中 created_at 是 TIMESTAMP，但 PostgreSQL 应用代码依赖带时区的时间戳做本地化展示。

在类型映射表中，把源类型 timestamp 映射为目标 timestamp with time zone
同时确保迁移时勾选 Convert timestamp to UTC（在 Advanced 选项里），否则 MySQL 原始值会按本地时区直接塞进 PG，造成逻辑错误
注意：如果源字段其实是 DATETIME，它没有时区信息，强行映射 with time zone 会导致所有值被解释为 UTC 时间，实际显示比原值快/慢若干小时

JSON 字段在 Oracle/SQL Server 中没有等价原生类型，得降级处理

MySQL 5.7+、PostgreSQL 9.4+ 支持 JSON 类型，但 Oracle（JSON 是 12cR2+ 且需开启功能）、SQL Server（JSON 仅是字符串解析函数，无独立类型）并不真正支持。Navicat 不会自动帮你降级成 CLOB 或 NVARCHAR(MAX)，默认可能映射失败或截断。

性能影响：用 VARCHAR(4000) 存大 JSON，Oracle 会频繁触发 LOB 操作；SQL Server 用 NVARCHAR(MAX) 虽可存，但无法用 ISJSON() 校验，索引也无效。

navicatmysql

Navicat For MySQL

下载

手动在映射表中将 json 映射为 clob（Oracle）或 nvarchar(max)（SQL Server）
Oracle 还需确认目标表空间支持 LOB，否则迁移报 ORA-01461: can bind a LONG value only for insert into a LONG column
SQL Server 若需后续校验 JSON 合法性，得在迁移后补建计算列 + ISJSON() 约束，Navicat 不生成这部分 DDL

自定义映射不保存，每次迁移/同步都要重配

Navicat 的类型映射规则是临时的，绑定在单次任务中。你花十分钟配好的 MySQL→PG 映射表，下次点开另一个 Data Transfer 向导，它又回到默认状态。没有“保存为模板”“导出映射配置”这类功能。

容易踩的坑：以为配过一次就能复用，结果新迁移发现 tinyint(1) 又被转成 smallint 而不是想要的 boolean，或者 enum 全变成 text。

唯一变通办法：把常用映射写成文本备忘，比如记下 “MySQL enum → PostgreSQL text”、“MySQL tinyint(1) → PostgreSQL boolean”
如果批量迁移多个库，建议先用命令行工具（如 pgloader 或 mysqldump + sed 预处理）统一转换，再用 Navicat 导入，避开映射反复配置
注意 Navicat 版本差异：16.x 开始支持在 Advanced 里导入/导出映射 JSON 文件（文件名类似 type_mapping.json），但仅限同一大版本间可用，15.x 配的不能直接给 16.x 用

最麻烦的其实不是配映射，而是不同数据库对“相同语义”的实现差异太大——比如 MySQL 的 auto_increment 和 PostgreSQL 的 serial，表面一样，背后序列管理、插入行为、复制兼容性全不一样。映射只是第一步，后面还得盯 DDL 生成是否合理、数据一致性有没有漏校验。