如何快速把 1 亿条 CSV 记录导入数据库？

为什么逐行 INSERT 是错误的工具

对每一行做一个朴素的 INSERT，要付出一次往返、一次解析、一次 WAL/redo 写入和一次 index 更新，共 1 亿次。即便每次只要 1ms，那也超过一天。批量路径通过摊薄所有这些而胜出：COPY 在一条协议消息中流式传输行，批量处理 WAL，并跳过逐语句的规划（planning）。在真实硬件上，单个 COPY 能达到每秒 10 万–50 万行，而 INSERT 只有每秒几千行。

各个组成部分

• **先用暂存表。**加载到一张一次性的表中（Postgres 的 UNLOGGED 完全跳过 WAL），绝不直接进线上表。这把加载与读者隔离，并让你能在发布前进行验证。
• **加载期间禁用 index 和约束。**每个二级 index 和 FK 检查都会对每一行重新求值。先删除它们，加载，然后一次性 CREATE INDEX——批量（排序）构建 index 远比 1 亿次增量更新便宜。
• **分块 + 并行。**按字节偏移把文件切成 N 段，运行 N 个 COPY 流。throughput 随 I/O 和 CPU 扩展，直到你让磁盘或 WAL 饱和。让 N 匹配核数/IOPS，而非"越多越好"。
• **幂等 + 可恢复。**给每个分块标一个 id；记录哪些分块已提交。重启时跳过已完成的分块。用 INSERT ... ON CONFLICT DO NOTHING/UPDATE（upsert）发布，使重跑绝不会重复插入。

面试视角

面试官在检查你是否知道批量路径的存在以及它为什么快数个数量级——而不是 COPY 语法。好："用 COPY"。出色："COPY 进一张 UNLOGGED 暂存表，删掉 index，并行分块，之后重建，用 upsert 发布，按分块 id 可恢复。"经典陷阱是循环 INSERT（或 ORM 的 saveAll）然后惊讶于它要花数小时；第二个陷阱是直接加载进线上表并阻塞生产。

权衡与故障模式

• UNLOGGED / 无 WAL 意味着没有崩溃恢复——对暂存表而言没问题，因为它是一次性的，但如果你对真实表这么做则是致命的。
• 并行度太高会让磁盘和 WAL 抖动（thrash）；越过饱和点后 throughput 反而下降。用基准测试找到最佳点。
• 重建 index 需要 maintenance_work_mem/临时空间；一次 1 亿行的 index 构建可能会溢写到磁盘。
• 脏 CSV（错误编码、内嵌分隔符）会让整个分块失败——在暂存表中验证类型，隔离被拒记录，让加载持续推进。