Antwort.

Das massenhafte Löschen von Dutzenden Millionen Zeilen ist eine der typischen und gefährlichen Operationen, insbesondere in stark belasteten Datenbanken. Historisch gesehen haben viele einfach DELETE FROM geschrieben, was zu Sperrungen der Tabelle und einer Überlastung des Transaktionsprotokolls führte. Das Hauptproblem: Die Transaktion wird zu groß, die unterstützenden Prozesse verlangsamen sich, und die Folgen eines Rollbacks können schwer vorhersehbar sein.

Lösung — Implementierung des Löschens "batchweise", wobei eine kleine Anzahl von Zeilen in einer Schleife mit kurzen Transaktionen verarbeitet wird, um Blockierungen und den Einfluss auf das System zu minimieren:

Beispielcode (SQL Server):

WHILE 1=1
BEGIN
   DELETE TOP (10000)
   FROM YourHugeTable
   WHERE CreatedAt < DATEADD(year,-2,GETDATE());

   IF @@ROWCOUNT = 0 BREAK;
   WAITFOR DELAY '00:00:01'; -- kleine Pause zur Verringerung der Last
END

Wichtige Merkmale:

Die Größe der Sperrungen und der Eintrag im Transaktionsprotokoll wird minimiert.
Die Verarbeitung erfolgt in kleinen Portionen: das System bleibt reaktionsschnell.
Kann mit der Anzeige des Fortschritts oder externer Überwachungslogik kombiniert werden.

Fangfragen.

Ist TRUNCATE immer schneller und sicherer als DELETE?

Nein. TRUNCATE ist zwar viel schneller, aber:

TRUNCATE kann nicht angewendet werden, wenn ein Fremdschlüssel auf die Tabelle verweist.
TRUNCATE löst keine Trigger aus.
TRUNCATE entfernt alle Zeilen vollständig und nicht nach Bedingung.

Ist es wichtig, Indizes auf dem Filterfeld bei massiven DELETE-Operationen zu verwenden?

Ja, das Vorhandensein eines geeigneten Index auf der Filterspalte (z.B. CreatedAt) beschleunigt die Suche nach zu löschenden Zeilen und verringert die Last auf der Tabelle. Ohne Index betrifft die Anfrage die gesamte Tabelle, selbst wenn in jedem Batch eine kleine Anzahl von Zeilen gelöscht wird.

CREATE INDEX idx_createdat ON YourHugeTable(CreatedAt);

Was passiert, wenn mehrere Threads gleichzeitig massives DELETE ausführen?

Das führt zu Konkurrenz um Blockierungen: es entstehen Sperrerhöhungen, die Wartezeit wächst und die Wahrscheinlichkeit eines Deadlocks steigt. Massives Löschen aus einer Tabelle sollte mit einem Prozess oder mit sehr sorgfältig durchdachten Bereichsaufteilungen erfolgen.

Typische Fehler und Anti-Pattern

Massives Löschen in einer einzigen Transaktion (blockiert die Tabelle, überlastet das Transaktionsprotokoll).
Fehlende Fortschrittsüberprüfung und Zeitkontrolle.
Fehlende Indizes — die gesamte Tabelle wird jedes Mal gescannt.

Beispiel aus der Praxis

Negativer Fall

Der DBA entschied sich, eine Tabelle mit 60 Millionen Zeilen mit einer einzigen Anfrage DELETE FROM Log WHERE dt < '2021-01-01' zu leeren. Der Server hing fast, andere Prozesse begannen zu warten, die Protokolldatei wuchs rasant an, die Wiederherstellung dauerte lange.

Vorteile:

Einfach zu implementieren.

Nachteile:

Wesentlicher Leistungsabfall des gesamten Servers, mögliches Datenverlustrisiko bei einem Absturz, lange Wiederherstellungszeit.

Positiver Fall

Das Löschen wurde in Pakete von 10.000 Zeilen aufgeteilt, der Prozess wird überwacht, nach jeder Portion gibt es eine Pause. Der Server funktioniert stabil, andere Aufgaben werden ausgeführt, der Administrator überwacht den Fortschritt.