Antwort.

Geschichte der Frage:

Bulk-Updates von Daten sind bei Migrationen, Übertragungen und Korrekturen von Geschäftslogik gefragt. Ein typisches Beispiel: Der Status von zehn Millionen Zeilen in einer aktiven Tabelle muss geändert werden, ohne den Dienst zu stoppen und die Verfügbarkeit und Leistung aufrechtzuerhalten.

Problem:

Ein gewöhnliches UPDATE ohne Einschränkungen funktioniert lange, kann zu Sperrerhöhungen führen, sperrt die Tabelle und führt bei einem Fehler zu einem kollektiven Rollback. Ein Ansatz ist erforderlich, der die Auswirkungen auf die Benutzer minimiert und die Transaktionsfähigkeit gewährleistet.

Lösung:

Teilen Sie die Operation in Chargen mit WHERE und LIMIT/TOP auf.
Verwenden Sie Fensterfunktionen, temporäre Tabellen und temporäre Marker.
Manchmal — vorübergehend Indizes abnehmen, Savepoints setzen, ein niedrigeres Isolationslevel verwenden.

Beispielcode:

-- Beispiel eines Batch-Updates von 10.000 Zeilen
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Hauptmerkmale:

Batch-Verarbeitung reduziert die Dauer der Sperrhaltung
Atomarität wird nur innerhalb jeder Mini-Transaktion garantiert
In einigen DBMS gibt es spezielle Bulk-Operatoren, die die Arbeit bei großen Datenmengen beschleunigen

Fangfragen.

Kann man ein Bulk UPDATE in einer Transaktion durchführen und die Tabelle nicht sperren?

Normalerweise nein. Eine große Transaktion sperrt die Tabelle/Seiten und erhöht das Risiko von Sperren und Zeitüberschreitungen. Es ist besser, in Chargen zu arbeiten.

Beeinflusst die Existenz von Indizes die Geschwindigkeit eines Bulk-Updates?

Ja. Jede Aktualisierung von indexierbaren Feldern erfordert einen Neuaufbau des Index für jede Zeile. Manchmal ist es sinnvoll, die Indizes vorübergehend abzunehmen, aber das erfordert eine gründliche Analyse.

Werden alle Zeilen atomar bei Batch-Updates aktualisiert?

Nein, die Atomarität wird nur innerhalb einer Charge (Limit von Zeilen/Transaktion) garantiert. Wenn eine Charge unterbrochen wird, werden einige Zeilen aktualisiert, einige nicht. Für echte Atomarität ist nur vollständiges UPDATE in einer Transaktion möglich, was bei großen Datenmengen riskant ist.

Typische Fehler und Anti-Patterns

Sofortiges UPDATE ohne Limit, das Sperrerhöhungen auslöst
Keine Berücksichtigung von Indizes — Erwartungen an hohe Leistung bei indexierbaren Spalten
Keine Verwendung von Savepoints (SAVEPOINT)

Beispiel aus dem Leben

Negativer Fall

Ein technischer Ingenieur beschloss, 10 Millionen Zeilen mit einer Abfrage in der Produktionsdatenbank zu aktualisieren: UPDATE mytable SET status = 'archived'. Die Webseite "fror ein", das Rollback dauerte Minuten, die Leistung litt.

Vorteile:

Einfachheit des Befehls, minimaler Code Nachteile:
Freeze/Sperrung des Produktionsdienstes
Möglicherweise große Rollbacks bei Fehlern

Positiver Fall

Die Abfrage wird in Chargen von 10.000 Zeilen mit kurzen Transaktionen aufgeteilt, das Update erfolgt während der Arbeitszeit ohne Ausfall.