Antwort.

Bulk UPDATE ist ein kritischer Vorgang, wenn eine große Anzahl von Zeilen in verknüpften Tabellen geändert wird. In der SQL-Historie ist die typische Implementierung ein UPDATE mit einer Unterabfrage oder JOIN. Problem: Jede massenhafte Aktualisierung ohne Steuerung der Ausführungsreihenfolge blockiert viele Zeilen, verursacht Lock-Eskalation und kann bei mehreren Aktualisierungen zu Deadlocks führen.

Lösung:

Teilen Sie UPDATE immer in kleine Chargen (zum Beispiel nach Primärschlüssel oder Datumsbereichen).
Verwenden Sie SET-orientierte Ansätze über JOIN, vermeiden Sie jedoch massenhafte Updates ohne Einschränkungen.
Wenden Sie gezielte Filter an, indizieren Sie die Felder gemäß den WHERE-Bedingungen und berücksichtigen Sie die Reihenfolge der Operationen für verknüpfte Tabellen.

Beispielcode (PostgreSQL):

UPDATE Orders o
SET status = 'archiviert'
FROM Customers c
WHERE o.customer_id = c.id
  AND c.closed = TRUE
  AND o.status != 'archiviert';

Oder in Chargen:

WITH upd AS (
   SELECT o.id
   FROM Orders o
   JOIN Customers c ON o.customer_id = c.id
   WHERE c.closed = TRUE
   AND o.status != 'archiviert'
   LIMIT 10000
)
UPDATE Orders
SET status = 'archiviert'
WHERE id IN (SELECT id FROM upd);

Schlüsselmerkmale:

Vermeiden Sie "das gesamte Table auf einmal" zu aktualisieren — immer batchen.
Verwenden Sie Indizes für das zu aktualisierende und das filternde Feld.
Definieren Sie klar die Auswahlbedingungen, um massenhafte Updates unnötiger Zeilen zu vermeiden.

Fangfragen.

Was passiert, wenn gleichzeitig UPDATEs ähnlicher Tabellen ohne Aufteilung in Bereiche oder gegenläufige Filter gestartet werden?

Wahrscheinlich treten Deadlocks auf: Prozesse blockieren dieselben Zeilen und warten aufeinander. Um dies zu vermeiden, sollten die Chargen sich nicht überschneiden oder strikt der Reihe nach ausgeführt werden.

Gibt es einen Unterschied zwischen UPDATE über JOIN und Unterabfrage, wenn es um massenhafte Statusänderungen geht?

Wenn geeignete Indizes vorhanden sind, besteht der Hauptunterschied nur in der Lesbarkeit und manchmal in der Leistung des spezifischen DBMS. JOIN ist in der Regel schneller, da es dem Optimierer ermöglicht, einen besseren Plan zu erstellen.

Wann ist es sinnvoll, TRUNCATE/DELETE anstelle von UPDATE zu verwenden?

Wenn die Geschäftslogik es zulässt — zum Beispiel, wenn archivierte Datensätze physisch gelöscht oder die Tabelle zurückgesetzt werden muss und nicht nur der Statusflag geändert wird. Aber für die massenhafte Statusaktualisierung — nur UPDATE.

Typische Fehler und Anti-Patterns

Massen-UPDATE "ohne Filter": Sperren, Rückrollungen, Deadlocks.
Fehlende Indizes — vollständige Tabellen-Scans.
Parallele Ausführung von UPDATEs ohne Aufteilung der Bereiche nach Schlüsseln.

Beispiel aus dem Leben

Negativer Fall

In einem großen Online-Shop wurden mehrere UPDATEs zur Änderung des Status von Bestellungen und Kunden gleichzeitig ohne Aufteilung nach Intervallen gestartet. Ergebnis: gegenseitige Sperrungen, mehrmals war ein erzwungener Rollback erforderlich und ungeschriebene Daten gingen verloren.

Vorteile:

Alles in einer Anfrage.

Nachteile:

Mögliche Deadlocks, Verlust der Leistung, große Datenmengen werden selbst bei kleinen Fehlern zurückgerollt.

Positiver Fall

Große Abfragen wurden in Chargen aufgeteilt, wurden strikt nacheinander ausgeführt und nur die erforderlichen Zeilen nach dem Filter verarbeitet.