ELIMINA vs TRUNCATO

Sto cercando di capire meglio le differenze tra i comandi DELETEe TRUNCATE. La mia comprensione degli interni va qualcosa del tipo di:

DELETE-> il motore di database trova e rimuove la riga dalle pagine di dati pertinenti e da tutte le pagine di indice in cui è inserita la riga. Pertanto, maggiore è il numero di indici, maggiore è il tempo necessario per l'eliminazione.

TRUNCATE -> rimuove semplicemente tutte le pagine di dati della tabella in massa rendendola un'opzione più efficiente per eliminare il contenuto di una tabella.

Supponendo che quanto sopra sia corretto (per favore correggimi se no):

1. In che modo le diverse modalità di recupero influenzano ogni istruzione? Se c'è qualche effetto
2. Durante l'eliminazione, vengono scansionati tutti gli indici o solo quelli in cui si trova la riga? Suppongo che tutti gli indici siano scansionati (e non cercati?)
3. Come vengono replicati i comandi? Il comando SQL viene inviato ed elaborato su ciascun abbonato? O MSSQL è un po 'più intelligente di così?

ELIMINA -> il motore di database trova e rimuove la riga dalle pagine di dati pertinenti e da tutte le pagine di indice in cui è inserita la riga. Pertanto, maggiore è il numero di indici, maggiore è il tempo necessario per l'eliminazione.

Sì, anche se ci sono due opzioni qui. Le righe possono essere eliminate da indici non cluster riga per riga dallo stesso operatore che esegue le eliminazioni della tabella di base. Questo è noto come piano di aggiornamento ristretto (o per riga):

Oppure, le eliminazioni di indici non cluster possono essere eseguite da operatori separati, uno per indice non cluster. In questo caso (noto come piano di aggiornamento ampio o per indice), il set completo di azioni viene archiviato in un piano di lavoro (spool desideroso) prima di essere riprodotto una volta per indice, spesso ordinato esplicitamente in base alle chiavi dell'indice non cluster per incoraggiare un sequenziale modello di accesso.

TRUNCATE -> rimuove semplicemente tutte le pagine di dati della tabella in massa rendendola un'opzione più efficiente per eliminare il contenuto di una tabella.

Sì. TRUNCATE TABLEè più efficiente per una serie di motivi:

1. Potrebbe essere necessario un numero inferiore di blocchi. Il troncamento richiede in genere solo un singolo blocco di modifica dello schema a livello di tabella (e blocchi esclusivi su ciascuna estensione allocata). L'eliminazione potrebbe acquisire blocchi con una granularità inferiore (riga o pagina) nonché blocchi esclusivi su tutte le pagine assegnate.
2. Solo il troncamento garantisce che tutte le pagine siano deallocate da una tabella heap. L'eliminazione può lasciare pagine vuote in un heap anche se viene specificato un suggerimento di blocco tabella esclusivo (ad esempio se per il database è abilitato un livello di isolamento del controllo delle versioni di riga).
3. Il troncamento viene sempre minimamente registrato (indipendentemente dal modello di recupero in uso). Nel registro delle transazioni vengono registrate solo le operazioni di deallocazione delle pagine.
4. Il troncamento può utilizzare il rilascio differito se l'oggetto ha dimensioni pari o superiori a 128. Drop differito significa che il lavoro di deallocazione effettivo viene eseguito in modo asincrono da un thread del server in background.

In che modo le diverse modalità di recupero influenzano ogni istruzione? C'è qualche effetto?

L'eliminazione viene sempre completamente registrata (ogni riga eliminata viene registrata nel registro delle transazioni). Vi sono alcune piccole differenze nel contenuto dei record di registro se il modello di recupero è diverso da quello FULL, ma si tratta ancora di una registrazione tecnicamente completa.

Durante l'eliminazione, vengono scansionati tutti gli indici o solo quelli in cui si trova la riga? Suppongo che tutti gli indici siano scansionati (e non cercati?)

L'eliminazione di una riga in un indice (utilizzando i piani di aggiornamento ristretto o largo mostrati in precedenza) è sempre un accesso per chiave (una ricerca). Scansionare l'intero indice per ogni riga cancellata sarebbe terribilmente inefficiente. Diamo un'occhiata al piano di aggiornamento per indice mostrato in precedenza:

I piani di esecuzione sono condotte guidate dalla domanda: gli operatori principali (a sinistra) spingono gli operatori figlio a fare il lavoro richiedendo una riga alla volta da loro. Gli operatori di ordinamento stanno bloccando (devono consumare l'intero input prima di produrre la prima riga ordinata), ma sono ancora guidati dal loro genitore (la cancellazione indice) che richiede quella prima riga. La cancellazione indice estrae una riga alla volta dall'ordinamento completato, aggiornando l'indice non cluster di destinazione per ogni riga.

In un ampio piano di aggiornamento, vedrai spesso le colonne aggiunte al flusso di righe dall'operatore di aggiornamento della tabella di base. In questo caso, l'eliminazione dell'indice cluster aggiunge colonne di chiave indice non cluster allo stream. Questi dati sono richiesti dal motore di archiviazione per individuare la riga da rimuovere dall'indice non cluster:

Come vengono replicati i comandi? Il comando SQL viene inviato ed elaborato su ciascun abbonato? O SQL Server è un po 'più intelligente di così?

Il troncamento non è consentito su una tabella pubblicata utilizzando la replica transazionale o di tipo merge. La modalità di replica delle eliminazioni dipende dal tipo di replica e dalla sua configurazione. Ad esempio, la replica di snapshot replica solo una vista temporizzata della tabella utilizzando metodi bulk: le modifiche incrementali non vengono monitorate o applicate. La replica transazionale funziona leggendo i record di registro e generando transazioni appropriate per applicare le modifiche agli abbonati. Unisci la replica tiene traccia delle modifiche utilizzando i trigger e le tabelle dei metadati.

Lettura correlata: ottimizzazione delle query T-SQL che modificano i dati