Antwoord.

Massaal verwijderen van tientallen miljoenen rijen is een van de typische en meest riskante operaties, vooral in hoogbelaste databases. Historisch gezien schreven velen gewoon DELETE FROM, wat leidde tot blokkades van de tabel en overbelasting van de transactie-log. Het belangrijkste probleem: de transactie wordt te groot, ondersteunende processen vertragen, en de gevolgen van rollback kunnen moeilijk te voorspellen zijn.

Oplossing — implementeer het verwijderen "batchgewijs" (batch), waarbij een klein aantal rijen in een cyclus wordt verwerkt met korte transacties om blokkeringen en de impact op het systeem te minimaliseren:

Voorbeeldcode (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'; -- korte pauze om de belasting te verlagen
END

Belangrijkste kenmerken:

De omvang van blokkeringen en logboekregistratie wordt geminimaliseerd.
Verwerking vindt plaats in kleine porties: het systeem blijft responsief.
Kan worden gecombineerd met voortgangsweergave of externe monitorlogica.

Vragen met een valstrik.

Is TRUNCATE altijd sneller en veiliger dan DELETE?

Nee. TRUNCATE is veel sneller, maar:

TRUNCATE kan niet worden toegepast als er een externe sleutel op de tabel verwijst.
TRUNCATE roept geen triggers aan.
TRUNCATE verwijdert alle rijen volledig, niet op basis van een voorwaarde.

Is het belangrijk om indexen te gebruiken op het filter veld bij massale DELETE?

Ja, het hebben van een geschikte index op de filterkolom (bijvoorbeeld CreatedAt) versnelt het zoeken naar te verwijderen rijen en vermindert de belasting op de tabel. Zonder index raakt de query de hele tabel, zelfs als er in elke portie een klein aantal rijen wordt verwijderd.

CREATE INDEX idx_createdat ON YourHugeTable(CreatedAt);

Wat gebeurt er als meerdere threads tegelijkertijd massale DELETE uitvoeren?

Dit leidt tot concurrentie om blokkeringen: er zullen blokkades escaleren, de wachttijd zal toenemen en de kans op deadlock. Massaal verwijderen uit één tabel moet met één proces worden uitgevoerd, of met een zeer zorgvuldig doordachte verdeling van intervallen.

Typische fouten en anti-patronen

Massaal verwijderen in één transactie (blokkeert de tabel, overbelast het transactie-log).
Ontbreken van voortgangscontrole en tijdsbeheer.
Ontbreken van indexen — de hele tabel wordt elke keer gescand.

Voorbeeld uit het leven

Negatieve case

DBA besloot de tabel met 60 miljoen rijen te wissen met een enkele DELETE FROM Log WHERE dt < '2021-01-01' query. De server "bevroren" bijna, andere processen begonnen te wachten, het logboekbestand groeide drastisch, herstel werd lang.

Voordelen:

Eenvoudig te implementeren.

Nadelen:

Significante prestatievermindering van de hele server, mogelijke dataverlies bij een storing, lang herstel.

Positieve case

Verwijdering werd in porties van 10.000 rijen uitgevoerd, het proces wordt gecontroleerd, na elke portie is er pauze. De server functioneert stabiel, andere taken worden uitgevoerd, de beheerder monitort de voortgang.