回答

データのバルクインサート（bulk insert）は、大きなテーブルの移行、インポート、または補充時に典型的な作業です。この操作の効率は、いくつかの要因に依存します：

バッチインサートの使用（Batch Insert）： データを合理的なパッケージに分割します（通常は一度に数千行）。これにより、トランザクションログへの負担が軽減され、ロックが減少します。
バルクインサート中のインデックスと制約の無効化： 二次インデックスや外部キーを一時的に削除または無効化することで、挿入が高速化します。操作が完了した後にインデックスを再作成してください。
トランザクションの制御： トランザクション内で固定数の行の挿入を行い、あまりにも大きなログファイルの蓄積を避けます。
特別なツールの使用： 例えば、BULK INSERTやCOPY（PostgreSQL）など、通常のINSERTループよりも高速に動作します。
必要な列のみを読み込む： 不要なデータを除外することで、トラフィック量と処理時間を減らします。

例（SQL Server）：

BULK INSERT my_table
FROM 'C:\data\bulkdata.csv'
WITH (
  FIELDTERMINATOR = ',',
  ROWTERMINATOR = '
',
  BATCHSIZE = 5000,
  TABLOCK
);

TABLOCKは、バルクインサート時のロックの競合を減少させます。

トリッキーな質問

質問： トランザクションに関与するテーブルで、バルクインサートを高速化するためにいつでもインデックスを無効化し再作成できますか？

回答： いいえ、テーブルがアクティブなトランザクションに関与している場合、インデックスの無効化や再作成はロックの発生、データ整合性の違反、あるいはトランザクションがロールバックされた場合のデータ損失を引き起こす可能性があります。この操作はトランザクション外でのみ実行するか、メンテナンスウィンドウを事前に計画する必要があります。

コード例：

-- 不適切：
BEGIN TRAN;
ALTER INDEX ALL ON my_table DISABLE;
-- ... bulk insert ...
ALTER INDEX ALL ON my_table REBUILD;
COMMIT;

長いトランザクション内でのこのような無効化は許可されません！

専門知識の不足による実際のエラーの例

ストーリー1：あるプロジェクトで、複数の一意のインデックスを持つテーブルへの並行バルクインサートが、頻繁なデッドロックとパフォーマンスの急落を引き起こしました。解決策は、インポート期間中の非キーインデックスの一時的な無効化と、バッチ操作のサイズの縮小でした。

ストーリー2：開発者たちはデータロードの期間中に外部キーの制約を無効にするのを忘れており、各インサートは他の大規模テーブルに関連するレコードの存在を確認していました。これにより、ロード時間が40分から9時間に増加しました。制約を無効にした後、挿入には12分かかりました。

ストーリー3：大きなファイルを単一のクエリで挿入しようとした（バッチ処理せず、トランザクションなし）ため、トランザクションログの容量が満杯になり、データベースサーバーがクラッシュしました。バッチ処理に移行した後、問題は解消されました。

SQLにおけるデータのバルクインサートの実装の特徴を、パフォーマンス、整合性、ロックの観点から説明してください。大規模データを扱う際に特に注意すべき点は何ですか？

回答

例（SQL Server）：

トリッキーな質問

コード例：

専門知識の不足による実際のエラーの例