DELETE vs TRUNCATE
J'essaie de mieux comprendre les différences entre les commandes DELETE et 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 il y a d'index, plus la suppression prend de temps.
TRUNCATE -> supprime simplement toutes les pages de données du tableau en masse, ce qui en fait une option plus efficace pour supprimer le contenu d'un tableau.
En supposant que ce qui précède est correct (veuillez me corriger sinon):
- Comment différents modes de récupération affectent-ils chaque instruction? S'il y a un quelconque effet
- Lors de la suppression, tous les index sont-ils analysés ou uniquement ceux où se trouve la ligne? Je suppose que tous les index sont scannés (et non recherchés?)
- Comment les commandes sont-elles répliquées? La commande SQL est-elle envoyée et traitée sur chaque abonné? Ou est-ce que MSSQL est un peu plus intelligent que ça?
SUPPRIMER -> 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 il y a d'index, plus la suppression prend de temps.
Oui, bien qu'il y ait deux options ici. Les lignes peuvent être supprimées des index non cluster ligne par ligne par le même opérateur qui effectue les suppressions de table de base. Il s'agit d'un plan de mise à jour étroit (ou par ligne):
Ou bien, les suppressions d'index non cluster peuvent être effectuées par des opérateurs distincts, un par index non cluster. Dans ce cas (connu sous le nom de plan de mise à jour large ou par index), l'ensemble complet des actions est stocké dans une table de travail (spool désireux) avant d'être relu une fois par index, souvent explicitement trié par les clés de l'index non cluster particulier pour encourager une séquence. modèle d'accès.
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.
Oui. TRUNCATE TABLE est plus efficace pour plusieurs raisons:
- Moins de verrous peuvent être nécessaires. La troncature ne requiert 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.
- Seule la troncature garantit que toutes les pages sont désallouées à partir d'une table de tas. La suppression peut laisser des pages vides dans un segment de mémoire même si un indice de verrouillage de table exclusif est spécifié (par exemple si un niveau d'isolement de version de ligne est activé pour la base de données).
- La troncature est toujours minimalement consignée (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.
- La troncature peut utiliser baisse différée si l'objet fait 128 étendues ou plus. La suppression différée 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 a-t-il un effet?
La suppression est toujours entièrement enregistré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 où se trouve la ligne? Je suppose que tous les index sont scannés (et non recherchés?)
La suppression d'une ligne dans un index (en utilisant les plans de mise à jour étroits ou larges présentés précédemment) est toujours un accès par clé (une recherche). L'analyse de l'index entier pour chaque ligne supprimée serait horriblement inefficace. Examinons à nouveau le plan de mise à jour par index présenté précédemment:
Les plans d'exécution sont des pipelines déterminés par la demande: les opérateurs parents (à gauche) poussent les opérateurs enfants à travailler en leur demandant une ligne à la fois. Les opérateurs de tri bloquent (ils doivent consommer l'intégralité de leur entrée avant de produire la première ligne triée), mais ils sont toujours piloté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é, en mettant à jour l'index cible non cluster pour chaque ligne.
Dans un plan de mise à jour étendu, vous verrez souvent des colonnes 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. Ces données sont requises par le moteur de stockage pour localiser la ligne à supprimer de l'index non cluster:
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 est non autorisée sur une table publiée à l'aide d'une réplication transactionnelle ou de fusion. La façon dont les suppressions sont répliquées dépend du type de réplication et de sa configuration. Par exemple, la réplication de cliché 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 fonctionne en lisant des enregistrements de journal et en générant des 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 associée: Optimisation des requêtes T-SQL qui modifient les données