Odpowiedź.

Masowe usuwanie dziesiątek milionów wierszy to jedna z typowych i najniebezpieczniejszych operacji, szczególnie w wysoko obciążonych bazach. Historycznie wielu po prostu pisało DELETE FROM, co prowadziło do blokady tabeli i przepełnienia dziennika transakcji. Główny problem: transakcja staje się zbyt duża, procesy obsługujące zwalniają, a skutki wycofania mogą być trudne do przewidzenia.

Rozwiązanie — zrealizować usuwanie "partiami" (batch), przetwarzając niewielką liczbę wierszy w pętli z krótkimi transakcjami, aby zminimalizować blokady i wpływ na system:

Przykład kodu (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'; -- mała przerwa dla zmniejszenia obciążenia
END

Kluczowe cechy:

• Minimalizuje się rozmiar blokad i zapis w dzienniku transakcji.
• Przetwarzanie odbywa się w małych porcjach: system pozostaje responsywny.
• Można połączyć z wyświetlaniem postępu lub zewnętrzną logiką monitorowania.

Pytania z podstępem.

Czy jeśli użyć TRUNCATE zamiast DELETE, zawsze będzie to szybsze i bezpieczniejsze?

Nie. TRUNCATE jest znacznie szybsze, ale :

1. TRUNCATE nie można zastosować, jeśli na tabelę wskazuje klucz obcy.
2. TRUNCATE nie wywołuje wyzwalaczy.
3. TRUNCATE całkowicie usuwa wszystkie wiersze, a nie według warunku.

Czy w masowym DELETE ważne jest używanie indeksów w polu filtrującym?

Tak, posiadanie odpowiedniego indeksu w kolumnie filtru (np. CreatedAt) przyspiesza wyszukiwanie usuwanych wierszy i zmniejsza obciążenie tabeli. Bez indeksu zapytanie obejmie całą tabelę, nawet jeśli w każdej porcji usuwana jest niewielka liczba wierszy.

CREATE INDEX idx_createdat ON YourHugeTable(CreatedAt);

Co się stanie, jeśli wykonywać kilka wątków masowego DELETE jednocześnie?

Spowoduje to rywalizację o blokady: wystąpią eskalacje blokad, wzrost czasu oczekiwania i prawdopodobieństwo deadlocka. Masowe usuwanie z jednej tabeli powinno być prowadzone przez jeden proces, lub z bardzo starannie przemyślonym podziałem zakresów.

Typowe błędy i antywzorce

• Masowe usuwanie w jednej transakcji (blokuje tabelę, przepełnia dziennik transakcji).
• Brak kontroli postępu i czasu wykonania.
• Brak indeksów — pełna tabela jest skanowana za każdym razem.

Przykład z życia

Negatywny przypadek

DBA postanowił wyczyścić tabelę mającą 60 mln wierszy jednoczesnym zapytaniem DELETE FROM Log WHERE dt < '2021-01-01'. Serwer prawie "zawisł", inne procesy zaczęły czekać na wykonanie, plik dziennika gwałtownie urósł, a odzyskiwanie stało się długie.

Zalety:

• Łatwe do zrealizowania.

Wady:

• Znaczny spadek wydajności całego serwera, możliwość utraty danych przy awarii, długi czas odzyskiwania.

Pozytywny przypadek

Usuwanie podzielono na partie po 10 000 wierszy, proces jest kontrolowany, po każdej porcji przerwa. Serwer działa stabilnie, inne zadania są realizowane, admin monitoruje postęp.

Zalety:

• Brak znacznego spadku wydajności.
• Brak ryzyka przepełnienia dziennika.

Wady:

• Operacja zajmuje więcej czasu do zakończenia, wymaga dodatkowej automatyzacji dla powtórzeń.