Odpowiedź.

Historia pytania:

Masowa aktualizacja danych jest potrzebna podczas przenoszenia, migracji, naprawy logiki biznesowej. Typowy przykład: musisz zmienić status dziesiątek milionów wierszy w tabeli roboczej, nie zatrzymując usługi, zachowując dostępność i wydajność.

Problem:

Zwykły UPDATE bez ograniczeń działa wolno, może prowadzić do eskalacji blokad, blokuje tabelę i prowadzi do zbiorczego wycofania w przypadku błędu. Potrzebne jest podejście, które minimalizuje wpływ na użytkowników i zapewnia transakcyjność.

Rozwiązanie:

Dzielić operację na paczki za pomocą WHERE i LIMIT/TOP.
Używać funkcji okiennych, tabel tymczasowych, znaczników czasowych.
Czasami — tymczasowo usuwać indeksy, ustawiać punkty zapisu (SAVEPOINT), używać niższego poziomu izolacji.

Przykład kodu:

-- Przykład aktualizacji paczki po 10 000 wierszy
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Kluczowe cechy:

Przetwarzanie paczek zmniejsza czas trwania blokad
Atomowość jest gwarantowana tylko w ramach każdej mini-transaction
W niektórych systemach DBMS są specjalne operatory bulk, które przyspieszają pracę przy dużych objętościach

Pytania z pazurem.

Czy można zrobić masowy UPDATE w jednej transakcji i nie zablokować tabeli?

Zazwyczaj nie. Duża transakcja blokuje tabelę/strony i zwiększa ryzyko blokad i timeoutów. Lepiej pracować w paczkach.

Czy obecność indeksów wpływa na prędkość masowej aktualizacji?

Tak. Każda aktualizacja pól indeksowanych wymaga przebudowy indeksu dla każdego wiersza. Czasami opłaca się tymczasowo usunąć indeksy, ale wymaga to głębokiej analizy.

Czy wszystkie wiersze są aktualizowane atomowo przy aktualizacjach paczkowych?

Nie, atomowość jest gwarantowana tylko w obrębie jednej paczki (limit wierszy/transakcji). Jeśli paczka zostanie przerwana, część wierszy będzie zaktualizowana, a część — nie. Dla prawdziwej atomowości — tylko pełny UPDATE w jednej transakcji, co jest niebezpieczne przy dużych objętościach.

Typowe błędy i antywzorce

Jednoczesny UPDATE bez limitu, prowadzący do eskalacji blokad
Nieuwzględnianie indeksów — oczekiwanie wysokiej wydajności na kolumnach indeksowanych
Nie korzystanie z punktów zapisu (SAVEPOINT)

Przykład z życia

Negatywny przypadek

Inżynier techniczny postanowił zaktualizować 10 mln wierszy jednym zapytaniem w produkcyjnej bazie danych: UPDATE mytable SET status = 'archived'. Strona "zamroziła się", wycofanie zajęło dziesiątki minut, wydajność ucierpiała.

Zalety:

Prostość polecenia, minimum kodu Wady:
Zamarzanie/blokowanie usługi produkcyjnej
Możliwe duże wycofanie transakcji w przypadku błędu

Pozytywny przypadek

Zapytanie podzielone na paczki po 10 000 wierszy z krótkimi transakcjami, aktualizacja odbywa się w godzinach roboczych bez przestojów.