Risposta.

Storia della domanda:

L'aggiornamento di massa dei dati è richiesto durante trasferimenti, migrazioni, correzioni della logica aziendale. Un esempio tipico: è necessario cambiare lo stato di decine di milioni di righe in una tabella di lavoro, senza fermare il servizio, mantenendo l'accessibilità e le prestazioni.

Problema:

Un normale UPDATE senza limitazione impiega molto tempo, può portare all'escalation dei blocchi, blocca la tabella e comporta un rollback collettivo in caso di errore. È necessario un approccio che minimizzi l'impatto sugli utenti e garantisca la transazionalità.

Soluzione:

Suddividere l'operazione in batch utilizzando WHERE e LIMIT/TOP.
Utilizzare funzioni di finestra, tabelle temporanee, marcatori temporanei.
A volte, rimuovere temporaneamente gli indici, fissare punti di salvataggio (SAVEPOINT), utilizzare un livello di isolamento più basso.

Esempio di codice:

-- Esempio di aggiornamento batch di 10.000 righe
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Caratteristiche chiave:

L'elaborazione batch riduce la durata del mantenimento dei blocchi
L'atomicità è garantita solo all'interno di ogni mini-transazione
In alcuni DBMS ci sono operatori bulk speciali che accelerano il lavoro con grandi volumi

Domande insidiose.

È possibile eseguire un aggiornamento di massa in un'unica transazione senza bloccare la tabella?

In genere, no. Una grande transazione blocca la tabella/pagine e aumenta il rischio di blocchi e timeout. È meglio lavorare in batch.

Influisce la presenza di indici sulla velocità dell'aggiornamento di massa?

Sì. Qualsiasi aggiornamento di campi indicizzati richiede una ricostruzione dell'indice per ogni riga. A volte è opportuno rimuovere temporaneamente gli indici, ma ciò richiede un'analisi approfondita.

Tutte le righe vengono aggiornate atomicamente durante gli aggiornamenti batch?

No, l'atomicità è garantita solo nell'ambito di un singolo batch (limite di righe/transazione). Se un batch si interrompe, alcune righe saranno aggiornate, altre no. Per una vera atomicità, solo un aggiornamento completo in un'unica transazione, il che è pericoloso per grandi volumi.

Errori tipici e anti-pattern

Aggiornamento simultaneo senza limite, causando escalation dei blocchi
Mancanza di considerazione per gli indici - aspettativa di elevate prestazioni su colonne indicizzate
Mancato utilizzo di punti di salvataggio (SAVEPOINT)

Esempi dalla vita reale

Caso negativo

Un ingegnere tecnico ha deciso di aggiornare 10 milioni di righe con una sola query in un database di produzione: UPDATE mytable SET status = 'archived'. Il sito si è bloccato, il rollback ha impiegato decine di minuti, le prestazioni ne hanno risentito.

Vantaggi:

Facilità del comando, minimo codice Svantaggi:
Freeze/blocco del servizio di produzione
Possibile grande rollback della transazione in caso di errore

Caso positivo

La query è stata suddivisa in batch di 10.000 righe con transazioni brevi, l'aggiornamento avviene durante l'orario lavorativo senza interruzioni.