回答。

複数の関連テーブルにおけるデータの大量更新は、SQLでの産業プログラミングにおける古典的な課題です。ビジネスアプリケーションの発展に伴い、大量のデータを同時に更新する必要が生じ、一貫性を保証することが求められました。従来は、ループ処理を用いたシナリオで対処していましたが、これはパフォーマンスが低下し、長時間のロックを引き起こす原因となっていました。その後、高度なDMLオペレーター（例えば、MERGE）、トランザクション構造、およびステージングテーブルを使ったアプローチが登場しました。

問題は、データの更新が注文とその詳細など、関連性のある多くのテーブルに影響を与えることにあります。これにより、「孤立行」（orphan rows）の発生や、ロックによるパフォーマンス低下、データベース管理システムへの予測不可能な負荷が生じる可能性があります。

解決策は、原子トランザクションを使用し、JOIN条件を持つUPDATE/DELETE/MERGE操作を行い、バッチ処理を採用することに基づいています。良い実践は、集計された変更を一時的なステージングテーブルに保留し、その後トランザクションを通じてバッチで適用することです。SQL ServerのMERGEを用いた例は以下の通りです：

BEGIN TRANSACTION;

-- MERGEを使用して主テーブルと関連テーブルを大量に更新する例
MERGE INTO orders AS tgt
USING temp_order_updates AS src
  ON tgt.id = src.id
WHEN MATCHED THEN
  UPDATE SET tgt.status = src.status, tgt.updated_at = src.updated_at;

MERGE INTO order_details AS tgt
USING temp_detail_updates AS src
  ON tgt.order_id = src.order_id AND tgt.sku = src.sku
WHEN MATCHED THEN
  UPDATE SET tgt.price = src.price, tgt.qty = src.qty;

COMMIT;

主な特徴：

操作を単一のトランザクションとして隔離する：中間的な不一致がない。
変更データの準備のためにステージングテーブルを使用する。
ブロックを減少させ、負荷を最適化するためにバッチ処理を適用する。

陷りやすい質問。

メインのテーブルを単に更新し、その後に関連テーブルを個別に更新することはできますか？トランザクションなしで、スピードに厳しい要求がある時に。

個別のUPDATEをトランザクションなしで行うと、どの段階でエラーが発生した場合でもデータが厳しく不一致になってしまいます。例えば、注文は更新されたが詳細は更新されなかった場合、ロジックが破綻します。現代のデータベース管理システムにおいて、トランザクションを使用することはバッチ処理時のオーバーヘッドをほとんど増加させません。

サブクエリを使用した単一の大きなUPDATEを行った場合、パフォーマンスは低下しますか？ブロックを引き起こすことがありますか？

はい、大きなテーブルへのモノリシックなUPDATEは、ロックのエスカレーションやテーブルロックを引き起こし、他のユーザーが待機状態になることがあります。処理をバッチに分け、WHERE ... AND rownum/id/limitを使用して制限する方が良いです。

バッチの例：

UPDATE orders
SET status = 'closed'
WHERE status = 'pending' AND id BETWEEN 100000 AND 199999;

MERGEは原子性と関連テーブルの処理順序を保証しますか？

いいえ、MERGEは単一のテーブル内でのみ機能します。関連テーブルを更新するには、別のMERGEまたはUPDATEが必要であり、必ず両方のアクションを単一のトランザクション内に配置する必要があります。

一般的な間違いとアンチパターン

大規模な変更時にトランザクションを使用しないため、データの不一致が発生する
巨大なサンプルに対する大規模な単一のUPDATE/DELETEにLIMIT/BATCHなし：ロックと待機状態
操作の順序が不適切（例：詳細を先に更新し、主テーブルをその後に更新）

実生活の例

ネガティブケース

ある会社が、トランザクションなしで別々のリクエストを通じて、100万件の注文のステータス（「完了」）を更新していました：主なorders、その後、詳細のorder_details。負荷がかかるとサーバーが「ダウン」し、エラーが発生した場合、詳細が「オープン」ステータスのままとなりました。 メリット:

簡単に実装できる
コードが最小限

デメリット:

データの不一致とその後のデバッグの難しさ
ロールバック時の複雑さ

ポジティブケース

ステージングテーブルとトランザクション内でのグループ処理を導入しました。最初にすべての変更を計算し、一時テーブルに保存し、その後に両方の主テーブルをバッチ更新しました。エラーが発生した場合は完全にロールバックします。 メリット:

データの一貫性と整合性を保証
コントロールとロールバックが容易