DELETE vs TRUNCATE

J'essaie de mieux comprendre les différences entre les commandes DELETEet TRUNCATE. Ma compréhension des éléments internes va dans le sens de:

DELETE-> le moteur de base de données recherche et supprime la ligne des pages de données pertinentes et de toutes les pages d'index où la ligne est entrée. Ainsi, plus la suppression prend de temps, plus il y a d'index.

TRUNCATE -> supprime simplement toutes les pages de données de la table en masse, ce qui en fait une option plus efficace pour supprimer le contenu d'une table.

En supposant que ce qui précède est correct (corrigez-moi s'il vous plaît sinon):

1. Comment différents modes de récupération affectent-ils chaque instruction? S'il y a un effet du tout
2. Lors de la suppression, tous les index sont-ils analysés ou uniquement ceux contenant la ligne? Je supposerais que tous les index sont scannés (et non recherchés?)
3. Comment les commandes sont-elles répliquées? La commande SQL est-elle envoyée et traitée sur chaque abonné? Ou MSSQL est-il un peu plus intelligent que cela?

DELETE -> le moteur de base de données trouve et supprime la ligne des pages de données pertinentes et de toutes les pages d'index où la ligne est entrée. Ainsi, plus la suppression prend de temps, plus il y a d'index.

Oui, bien qu'il y ait deux options ici. Les lignes peuvent être supprimées des index non clusterisés, ligne par ligne, par le même opérateur que celui qui effectue les suppressions de la table de base. Ce plan est appelé plan de mise à jour étroit (ou par ligne):

Ou bien, les suppressions d'index non clusterisés peuvent être effectuées par des opérateurs distincts, un par index non clusterisé. Dans ce cas (connu sous le nom de plan de mise à jour étendu ou d'index), l'ensemble complet d'actions est stocké dans une table de travail (spool) avant d'être réexécuté une fois par index, souvent explicitement trié par les clés de l'index non clusterisé particulier afin d'encourager une exécution séquentielle. modèle d'accès.

TRUNCATE -> supprime simplement toutes les pages de données de la table, ce qui en fait une option plus efficace pour supprimer le contenu d'une table.

Oui. TRUNCATE TABLEest plus efficace pour un certain nombre de raisons:

1. Moins de verrous peuvent être nécessaires. La troncature ne nécessite généralement qu'un seul verrou de modification de schéma au niveau de la table (et des verrous exclusifs sur chaque étendue désallouée). La suppression peut acquérir des verrous à une granularité inférieure (ligne ou page) ainsi que des verrous exclusifs sur toutes les pages désallouées.
2. Seule la troncature garantit que toutes les pages sont désallouées d'une table de tas. La suppression peut laisser des pages vides dans un segment de mémoire même si un indicateur de verrou de table exclusif est spécifié (par exemple, si un niveau d'isolation de versioning de ligne est activé pour la base de données).
3. La troncature est toujours journalisée de manière minimale (quel que soit le modèle de récupération utilisé). Seules les opérations de désallocation de page sont enregistrées dans le journal des transactions.
4. La troncature peut utiliser la suppression différée si la taille de l'objet est égale ou supérieure à 128 étendues. Drop différé signifie que le travail de désallocation réel est effectué de manière asynchrone par un thread de serveur d'arrière-plan.

Comment différents modes de récupération affectent-ils chaque instruction? Y at-il un effet du tout?

La suppression est toujours entièrement journalisée (chaque ligne supprimée est enregistrée dans le journal des transactions). Il existe quelques petites différences dans le contenu des enregistrements de journal si le modèle de récupération est différent de FULL, mais il s'agit toujours d'une journalisation techniquement complète.

Lors de la suppression, tous les index sont-ils analysés ou uniquement ceux contenant la ligne? Je supposerais que tous les index sont scannés (et non recherchés?)

La suppression d'une ligne dans un index (à l'aide des plans de mise à jour étroit ou étendu présentés précédemment) est toujours un accès par clé (une recherche). Analyser l'intégralité de l'index pour chaque ligne supprimée serait terriblement inefficace. Examinons à nouveau le plan de mise à jour par index présenté précédemment:

Les plans d'exécution sont des pipelines basés sur la demande: les opérateurs parents (à gauche) amènent les opérateurs enfants à effectuer leur travail en leur demandant une ligne à la fois. Les opérateurs de tri bloquent (ils doivent utiliser toute leur entrée avant de produire la première ligne triée), mais ils sont toujours contrôlés par leur parent (la suppression d'index) qui demande cette première ligne. La suppression d'index extrait une ligne à la fois du tri terminé et met à jour l'index non cluster ciblé pour chaque ligne.

Dans un plan de mise à jour étendu, vous verrez souvent que des colonnes sont ajoutées au flux de lignes par l'opérateur de mise à jour de la table de base. Dans ce cas, la suppression d'index en cluster ajoute des colonnes de clé d'index non clusterisées au flux. Le moteur de stockage a besoin de ces données pour localiser la ligne à supprimer de l'index non clusterisé:

Comment les commandes sont-elles répliquées? La commande SQL est-elle envoyée et traitée sur chaque abonné? Ou SQL Server est-il un peu plus intelligent que cela?

La troncature n'est pas autorisée sur une table publiée à l'aide de la réplication transactionnelle ou de fusion. La manière dont les suppressions sont répliquées dépend du type de réplication et de sa configuration. Par exemple, la réplication d'instantané réplique simplement une vue ponctuelle de la table à l'aide de méthodes en bloc: les modifications incrémentielles ne sont ni suivies ni appliquées. La réplication transactionnelle consiste à lire les enregistrements du journal et à générer les transactions appropriées pour appliquer les modifications aux abonnés. La réplication de fusion suit les modifications à l'aide de déclencheurs et de tables de métadonnées.

Lecture connexe: Optimisation des requêtes T-SQL modifiant les données