navicat导入千万级csv会卡死或失败，因其导入向导采用客户端内存加载+批量insert架构，无法支撑大文件；应改用load data infile或copy命令，或启用navicat批量模式、拆分文件、手动指定字段类型并关闭自动格式识别。
Navicat导入千万级CSV会卡死或失败？先确认是否真需要“全量一次性导入”
Navicat的导入向导本质是客户端驱动的批量INSERT，不是服务端COPY。当CSV超过500万行、体积超800MB时，内存占用陡增，UI常无响应、中途崩溃，或报错Out of memory、Connection timeout。这不是配置问题，而是架构限制——它把整份CSV读进本地内存做映射和校验，再分批发往数据库。真正能扛住千万级的，只有PostgreSQL原生COPY或MySQL的LOAD DATA INFILE。Navicat只适合预处理+小批量验证，别把它当ETL引擎用。
必须用Navicat时：启用“批量模式”并拆分文件
如果硬要走Navicat流程（比如权限受限、无法直连服务器），必须绕过内存瓶颈：
- 在导入向导第5步“为源定义附加选项”中，勾选
启用批量模式，并手动设每批记录数 = 10000（默认500太保守，但别超50000，否则PG事务日志暴涨） - 用
split -l 200000 your_data.csv chunk_把大文件切为20万行/片（注意保留表头：第一片加-l 199999，后续补头） - 编码统一用
UTF-8，禁用GBK——后者在大文件中极易因BOM或混合编码触发解析中断 - 关闭Navicat“自动检测字段类型”，所有列先映射为
TEXT，导入完成后再用ALTER TABLE ... ALTER COLUMN ... TYPE批量转类型，避免导入时类型推断耗时翻倍
日期/数字字段映射错乱？关掉“自动格式识别”手动指定
千万级CSV里常混着2023/01/01、01-Jan-2023、空字符串甚至NULL，Navicat默认开启的自动识别日期/数字格式会逐行扫描、反复回溯，导致速度断崖式下跌，且容易把123456789误判为时间戳。解决方式很直接：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 在导入向导第6步“字段映射”界面，点击右下角
高级按钮 - 取消勾选
自动识别日期格式和自动识别数字格式 - 对日期列，在“目标字段类型”下拉中手动选
TIMESTAMP或DATE，并在“源格式”栏填严格匹配的模板，如YYYY-MM-DD HH24:MI:SS - 对含千分位或货币符号的数字列（如
$1,234.56），先在CSV里用sed 's/[$,]//g'清洗，再映射为NUMERIC
导入后数据不全或主键冲突？检查Navicat的“错误处理策略”设置
默认情况下，Navicat遇到单条记录错误（如违反NOT NULL、类型转换失败）会直接中断整个批次。千万级数据里藏几条脏数据太正常，不能因小失大：
- 在导入向导最后一步“选择导入方式”页，务必点开
错误处理设置 - 将
错误处理策略从停止导入改为跳过错误记录 - 勾选
保存错误日志到文件，路径设为本地可写目录（如/tmp/navicat_errors.log），方便事后定位哪几行坏了 - 若目标表有
SERIAL主键，确保CSV里没填该列——Navicat不会自动忽略，会报duplicate key，应提前删掉CSV对应列或在映射中不勾选
最易被忽略的一点：Navicat导入过程依赖本地机器性能，而非数据库服务器。即使你的PostgreSQL跑在32核服务器上，只要Navicat装在8GB内存的笔记本里，它照样卡死。真要导千万级，优先走psql -c "\COPY ... FROM ..."或pg_restore，Navicat只用来建表、调参、查错。
