navicat 17 原生不支持 parquet 文件导入，因其无内置 parquet 解析器；必须先用外部工具（如 duckdb）将 parquet 转为 csv 或 sql，再通过 navicat 导入，或直接使用 mysql 的 load data infile 命令行方式提升效率与稳定性。
Navicat 17 原生不支持 Parquet 文件导入
Navicat 17 的“导入向导”和“运行SQL文件”功能完全不识别 .parquet 文件——它没有内置 Parquet 解析器，也不会调用 Arrow 或 PyArrow 库。你双击选择 data.parquet，会直接提示“不支持的文件类型”或静默跳过。这不是配置问题，是功能缺失。所有声称“Navicat 可直导 Parquet”的教程，要么混淆了 Navicat Data Modeler（仅用于建模，不处理数据），要么把 Zilliz Cloud / Milvus 的导入流程错贴到了 Navicat 上。
真正可行的路径：先转成 Navicat 能认的格式
必须在导入前完成格式转换，核心原则是：**用外部工具把 Parquet 转成 CSV 或 SQL，再交给 Navicat**。推荐组合如下：
- 小到中等规模（pyarrow +
pandas导出为 CSV，注意设置index=False、encoding='utf-8'、quoting=csv.QUOTE_MINIMAL - 超大文件（>2GB）或含嵌套结构：用
duckdbCLI 执行EXPORT DATABASE 'output_dir' (FORMAT CSV)，它能自动分块、跳过 Parquet 中的 unsupported type（如 struct/map） - 需要保留严格数据类型和 NULL 行为：导出为标准 SQL 插入语句（
INSERT INTO t VALUES (),(),()...），但务必确保每条VALUES行不超过max_allowed_packet限制（建议单批 ≤ 1000 行）
别用 Excel 中转——Parquet 里的 timestamp、decimal、binary 字段极易在 Excel 里被自动格式化失真。
导入 CSV 时最容易踩的三个坑
即使格式转对了，Navicat 导入 CSV 仍常失败，关键在细节：
-
NULL字符串必须显式设为\N（不是空字符串、不是NULL文本），并在导入向导中勾选“将空字符串转换为 NULL” - 时间字段（
TIMESTAMP/DATETIME）的原始值必须是YYYY-MM-DD HH:MM:SS格式；若 Parquet 里存的是毫秒级 Unix 时间戳，需提前转成可读格式，Navicat 不解析数字时间戳 - CSV 文件必须用
LF换行（Unix 风格），Windows 的CRLF在某些 Navicat 17 版本里会导致最后一列截断——用dos2unix或 VS Code 的换行符切换功能修复
比“导入”更稳的替代方案：走 MySQL 命令行 + LOAD DATA
如果你有服务器 SSH 权限，且目标是 MySQL/MariaDB，绕过 Navicat 更快更可靠：
- 把 CSV 上传到数据库服务器本地（如
/tmp/data.csv） - 在 Navicat 查询窗口执行：
LOAD DATA INFILE '/tmp/data.csv' INTO TABLE your_table FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 ROWS; - 前提是 MySQL 已开启
local_infile=ON，且用户有FILE权限；若报错Secure File Priv，改用LOAD DATA LOCAL INFILE并确认客户端也启用该选项
这条命令比 Navicat 导入快 5–10 倍，且不占 Navicat 内存，不会因文件太大触发 java.lang.OutOfMemoryError。真正的瓶颈从来不在 Navicat 界面，而在它强行把服务端任务拉到客户端做。
