Navicat 导入 DDL 时 text 被降级为 varchar(255) 是因默认映射策略所致，需在结构同步中手动将字段映射改为 TEXT 并确认生成脚本；PostgreSQL 数组字段被识别为 text 需人工修改 DDL 或改用 pg_dump；MySQL datetime 映射错误需按语义指定目标类型；“ERROR 1046”须先双击打开目标数据库再导入 SQL 文件。
Navicat 导入 DDL 后 text 变成 varchar(255) 怎么办
这是 navicat 对 mysql text 类型的默认降级行为，不是解析错误，而是它把源库的 text 映射成了目标库“看起来最像”的可变长字符串类型——但 varchar(255) 有长度限制，而 text 没有，插入超长内容时直接报错。
修复必须在导入前干预：进入「结构同步」或「数据传输」向导 → 点「字段映射」→ 找到被转成 varchar(255) 的列 → 手动改为 TEXT（注意大小写，MySQL 区分）。
- 如果源是 PostgreSQL 的
text，目标 MySQL 也必须填TEXT，不能留空或选VARCHAR - Navicat 不会自动继承源字段的
NOT NULL或默认值，这些需单独勾选/填写 - 改完后务必点「查看脚本」确认生成的 DDL 确实是
content TEXT，而不是content VARCHAR(255)
PostgreSQL 数组字段（如 tags text[]）被同步成 text 怎么补
Navicat 16.2 以下版本根本不识别 PostgreSQL 数组语法，它读取 pg_attribute.atttypid 后只查基础类型名，丢弃了 pg_type.typarray 和 attndims 元数据，结果就是所有 text[] 都变成 text。
无法靠设置修复，只能人工拦截 DDL：
- 在「结构同步」点击「下一步」后，立刻点「查看脚本」
- 搜索
ADD COLUMN tags text或tags ARRAY这类行 - 改成
tags text[]（不能写ARRAY单独存在，PostgreSQL 不认） - 对已有表执行
ALTER TABLE ALTER COLUMN tags TYPE text[] USING tags::text[]
若同步涉及多个数组字段，建议放弃图形化同步，改用 pg_dump -s -t table_name db_name > schema.sql 直接导出原生 DDL。
MySQL datetime 被映射成 timestamp without time zone 导致时间偏移
Navicat 默认把 MySQL 的 DATETIME 和 TIMESTAMP 都映射为 PostgreSQL 的 timestamp without time zone，但语义完全不同：DATETIME 是本地时间字面量，TIMESTAMP 存 UTC；而 timestamp without time zone 在 PG 里不做时区转换，直接按字面解释——结果就是显示快/慢 8 小时。
正确做法是在字段映射中显式指定：
- 源类型填
datetime，目标类型填timestamp without time zone（仅当业务确定不需要时区） - 源类型填
timestamp，目标类型必须填timestamp with time zone，并勾选「Convert timestamp to UTC」 - 如果目标库已建表且类型错误，用
ALTER TABLE ALTER COLUMN created_at TYPE timestamp with time zone USING created_at AT TIME ZONE 'UTC'修正
导入 SQL 文件时报 “ERROR 1046: No database selected”
这不是字段类型问题，但常和 DDL 导入失败混淆——Navicat 在执行 CREATE TABLE 前没选定数据库上下文，所以报错。
解决方法极简单，但容易忽略：
- 在左侧连接列表中，**必须先双击打开目标数据库**（比如
myapp_prod），再右键 → 「运行 SQL 文件」 - 不要直接在连接根节点（如
localhost）上导入，那会丢失 database context - 如果 SQL 文件开头没有
USE myapp_prod;，Navicat 不会自动补，也不能靠连接属性里的「默认数据库」兜底
真正麻烦的是混合场景：DDL 里既有 CREATE DATABASE 又有 CREATE TABLE，这时必须确保 USE 语句在第一个 CREATE TABLE 之前，否则 Navicat 仍会卡在 1046。
