回答。

大量のデータをインポート（バルクインサート）するためには、専門のコマンドやユーティリティが使用されます： BULK INSERT、 COPY、 LOAD DATA INFILE、外部ツール（SQL Serverのbcp、PostgreSQLのpsql）、およびETLユーティリティ。

重要なポイント：

不要な変換なしでCSV/TXT形式を使用してください。
インポート中はトリガーとインデックスをオフにしてください。データの検証が不要な場合、これにより速度が向上します。
インポートの前後に参照整合性のチェックと検証を行ってください。
一時テーブルにインポートし、検証後に本テーブルにバルク挿入します。
サポートされている場合、データをバッチに分割するようにしてください。
戻りコード/ログを確認してください - バルクインサートは失敗をスキップする可能性があります。

PostgreSQLの例：

COPY staging_table (id, name, age)
FROM '/path/to/data.csv'
DELIMITER ','
CSV HEADER;

-- データをチェックし、検証後に本テーブルに移行
INSERT INTO prod_table (id, name, age)
SELECT id, name, age FROM staging_table WHERE age >= 0 AND name IS NOT NULL;

ひっかけ質問。

質問： なぜインデックスのある大規模テーブルにバルクインサートした後、次の操作のパフォーマンスが急激に低下するのですか？

回答： バルクインサートはテーブルに直接データを挿入するため、インデックスは主なインポートが完了した後にのみ再構築/更新されます。これによりテーブルがロックされ、リソースを消費する可能性があります。インポート中はセカンダリインデックスをオフにし、終了後に再作成するか、バッチに分割することが推奨されます。

逸話

物流プロジェクトでは、一時テーブルを介さずにBULK INSERTで何百万行も挿入しましたが、不正なデータがインデックスを無効な情報で埋め、FKやチェック制約により不良データの一部を簡単に「ロールバック」できませんでした。データを手動でクリーンアップする必要がありました。

逸話

企業サービスでは、バルクインサートがインポート時間を10倍に増加させました。なぜなら、挿入中にセカンダリインデックスがオフにされず、各ステップでその構造が再計算されていたからです。

逸話

フィンテック製品では、大きなファイルのインポート中にバルクインサートが正常に処理されず、重要な情報を失う結果となりました。エラコードが正しく処理されていなかったため、数日後に外部ソースとの照合でようやく発覚しました。