Navicat 17 不支持直接导入 Parquet 文件，因其导入向导仅识别 TXT、CSV、XML、JSON 等文本格式，而 Parquet 是含 schema 元数据和压缩数据页的二进制列式格式，无法被文本解析器识别。
navicat 17 不支持直接导入 parquet 文件。 它的导入向导只识别 txt、csv、xml、json 和部分 dat（当作文本处理），而 parquet 是二进制列式格式，navicat 没有内置解析器——你点“选择文件”时根本看不到 .parquet 后缀，强行改后缀为 .csv 或 .txt 也会在解析阶段报 invalid file format 或直接卡死。
为什么 Navicat 17 的导入向导打不开 .parquet 文件
Navicat 17 的「导入向导」底层调用的是基于文本流的解析逻辑，所有支持格式都满足两个前提：可逐行读取、字段分隔明确。Parquet 文件是 Apache Arrow 生态下的二进制序列化格式，含 schema 元数据块、压缩数据页、字典编码等结构，无法被文本解析器识别。即使你用 Python 把 Parquet 转成 CSV 再导入，也得先确保字段类型和 null 处理方式对齐，否则 timestamp 列可能变成毫秒整数、decimal 精度丢失、嵌套 struct 字段直接塌陷为 JSON 字符串。
绕过限制的可行路径：先转 CSV/JSON，再导入
真正能落地的操作只有这一条链路：用外部工具把 Parquet 转成 Navicat 可读的中间格式，并严格控制转换参数：
- 用
pyarrow或pandas读取 Parquet，调用to_csv()时指定：index=False、date_format='%Y-%m-%d %H:%M:%S'、na_rep='NULL'（避免空字符串或NaN被误判） - 如果原 Parquet 含
list或struct字段，必须提前展开——Navicat 不理解嵌套，to_csv()默认会把整个结构转成 JSON 字符串，导致目标表字段类型不匹配 - 导出 CSV 后，用记事本另存为
UTF-8 无 BOM编码；若字段含中文或特殊符号，还要确认 CSV 分隔符是纯\t或,，不能混用空格或不可见字符 - 在 Navicat 导入向导第 2 步「字段映射」中，务必关闭「第一行包含字段名」——除非你明确在 CSV 顶部加了与目标表完全一致的列名（大小写、下划线、无空格）
Schema 兼容性最容易被忽略的三个点
很多人以为只要列名对上就万事大吉，实际掉坑最多的是这三处：
-
timestamp和timestamptz：Parquet 里的时间戳默认带时区信息，但转 CSV 时若没用utc=True参数，会丢时区偏移；Navicat 导入时若目标字段是TIMESTAMP WITHOUT TIME ZONE（如 PostgreSQL 的timestamp），就会把 +08:00 的值截断，变成本地时间错乱 -
decimal(18,2)类型：Pandas 默认转成 float64，小数点后位数可能多出 1~2 位（如100.00变成100.00000000000001），导入 MySQL 时触发Data truncated for column 'price' - NULL 值表示法：Parquet 中的 null 在 CSV 里该写成空字段（
col1,,col3）还是NULL字符串？Navicat 的「空值字符串」设置必须和导出时的na_rep严格一致，否则 NOT NULL 字段收到空字符串就直接报错
真正麻烦的不是操作步骤，而是 Parquet 的 schema 隐式特性——比如同一列在不同 row group 里可能有不同精度的 decimal，或 string 字段混着 null 和空字符串。这些在转 CSV 时不会报错，但会在 Navicat 导入后暴露为数据异常。建议先导出前 100 行做验证，比硬导几百万行再回溯强得多。
