1億件のCSVレコードを高速にDBへインポートするにはどうしますか？

なぜ行ごとのINSERTが誤ったツールなのか

素朴な行ごとの INSERT は、ラウンドトリップ、パース、WAL/redo書き込み、インデックス更新を1億回支払います。各1msでも1日を超えます。バルクパスはこれらすべてを償却して勝ちます。COPY は1つのプロトコルメッセージで行をストリームし、WALをバッチ化し、ステートメントごとのプランニングをスキップします。実機では単一の COPY がINSERTの数千に対し10万〜50万行/秒を出します。

可動部

• まずステージングテーブル。 使い捨てテーブル（Postgresの UNLOGGED はWALを完全にスキップ）にロードし、決してライブテーブルへ直接ロードしません。これでロードを読み手から隔離し、公開前に検証できます。
• ロード中はインデックスと制約を無効化。 すべてのセカンダリインデックスとFKチェックは行ごとに再評価されます。ドロップしてロードし、その後 CREATE INDEX を一度だけ。バルク（ソート済み）でのインデックス構築は1億の逐次更新よりはるかに安価です。
• チャンク + 並列化。 ファイルをバイトオフセットでN片に分割し、N個の COPY ストリームを実行します。スループットはディスクやWALを飽和させるまでI/OとCPUに応じてスケールします。「できるだけ多く」ではなく、Nをコア数/IOPSに合わせます。
• 冪等 + 再開可能。 各チャンクにidを付け、どのチャンクがコミットしたかを記録します。再起動時に完了済みチャンクをスキップします。INSERT ... ON CONFLICT DO NOTHING/UPDATE（upsert）で公開し、再実行が決して二重挿入しないようにします。

面接での観点

面接官は、あなたがバルクパスの存在と、なぜそれが桁違いに速いのかを知っているかを確認します。COPYの構文ではありません。良い：「COPYを使う」。優れた：「UNLOGGEDのステージングテーブルへCOPY、インデックスをドロップ、並列チャンク、後で再構築、upsertで公開、チャンクidで再開可能」。典型的な罠はINSERTのループ（またはORMの saveAll）で、何時間もかかって驚くこと。第2の罠は、ライブテーブルへ直接ロードして本番をブロックすることです。

トレードオフと障害モード

• UNLOGGED / WALなしはクラッシュリカバリがないステージングテーブルには問題ありません（使い捨てだから）が、本番テーブルにやれば致命的です。
• 並列が高すぎるとディスクとWALをスラッシュします。飽和を超えるとスループットが下がります。スイートスポットをベンチマークします。
• インデックス再構築には maintenance_work_mem/一時領域が必要。1億行のインデックス構築はディスクにあふれえます。
• 汚れたCSV（不正なエンコーディング、埋め込み区切り文字）はチャンク全体を失敗させます。ステージングで型を検証し、拒否分を隔離し、ロードを止めないようにします。