Sql Sql Server Indexing

Comprendre les Différences entre un Scan de Table et un Scan d’Index Clusterisé

Lorsque vous travaillez avec des bases de données, vous avez peut-être rencontré les termes Scan de Table et Scan d’Index Clusterisé. Bien que les deux méthodes soient conçues pour accéder aux données dans une base de données SQL Server, elles fonctionnent différemment et ont des implications de performance variées. Dans cet article de blog, nous allons explorer les différences fondamentales entre elles et pourquoi l’une peut être considérée comme meilleure que l’autre.

Qu’est-ce qu’un Scan de Table ?

Un Scan de Table se produit lorsque le moteur de base de données lit toutes les pages de données d’une table pour trouver les lignes qui correspondent à une condition spécifique. Cette méthode est simple mais inefficace, surtout si la table contient un grand nombre d’enregistrements.

  • Table Heap : Si une table n’a pas d’index clusterisé, elle est catégorisée comme une table heap. Cela signifie que les pages de données ne sont pas organisées dans un ordre spécifique, ce qui conduit à ce qui suit :
    • Aucune page de données liée
    • Des recherches dans la Carte d’Allocation d’Index (IAM) sont nécessaires pour traverser les pages.

Qu’est-ce qu’un Scan d’Index Clusterisé ?

En revanche, un Scan d’Index Clusterisé utilise un index clusterisé pour accéder aux données de manière plus efficace. Dans une table clusterisée, les pages de données sont organisées dans un ordre spécifique (selon la colonne indexée), ce qui permet d’améliorer les performances lors des scans.

  • Liste Doublement Chaînée : Les pages de données sont reliées par une liste doublement chaînée. Cela signifie :
    • Les scans séquentiels peuvent être effectués plus rapidement.
    • Moins de surcharge lorsqu’il s’agit de trouver une ligne de données spécifique, puisque les données sont triées.

Comparaison de Performance : Scan de Table vs. Scan d’Index Clusterisé

Examinons plus en détail pourquoi un Scan d’Index Clusterisé est souvent préféré à un Scan de Table avec un exemple.

Exemple de Requête

Prenons l’exemple suivant :

  1. Sans Index Clusterisé (Table Heap) :

    DECLARE @temp TABLE (SomeColumn VARCHAR(50));
INSERT INTO @temp SELECT 'SomeVal';
SELECT * FROM @temp;

  2. Avec un Index Clusterisé :

    DECLARE @temp TABLE (RowID INT NOT NULL IDENTITY(1,1) PRIMARY KEY, SomeColumn VARCHAR(50));
INSERT INTO @temp SELECT 'SomeVal';
SELECT * FROM @temp;

Analyse de la Performance

Voici comment les deux méthodes se comparent l’une à l’autre :

  • Scan de Table :

    • Le scan nécessite de parcourir toutes les pages.
    • Utilise une deuxième écriture dans l’IAM, ce qui peut ralentir la performance.

  • Scan d’Index Clusterisé :

    • Comme les données sont ordonnées, lorsqu’une requête avec une clause WHERE est exécutée, cela peut réduire considérablement la quantité de données scannées.
    • Même pour les requêtes qui récupèrent toutes les lignes, la nature liée des pages rend cela légèrement plus rapide qu’une heap.

Quand Utiliser Chaque Méthode

  • Scan d’Index Clusterisé est généralement plus efficace parce que :

    • Il peut traiter efficacement les requêtes de plage.
    • Permet des performances optimales via des opérations de recherche d’index clusterisé.

  • Scan de Table est moins efficace dans les situations où :

    • Il y a un nombre significatif d’enregistrements et aucun ordre.
    • Vous avez des recherches conditionnelles qui ne peuvent pas tirer parti d’une structure indexée.

Implications pour les Opérations d’Insertion, de Mise à Jour et de Suppression

  • Performance des INSERT, UPDATE et DELETE :

    • Dans des expériences, les index clusterisés ont montré de meilleures performances par rapport aux tables heap en :
      • INSERT (3% plus rapide)
      • UPDATE (8% plus rapide)
      • DELETE (18% plus rapide)

  • Cependant, les tables heap peuvent voir des bénéfices de performance sous des conditions de charge lourde en raison d’une surcharge d’entretien plus faible, mais au coût de récupérations plus lentes lors d’opérations de recherche.

Conclusion

En résumé, bien que les Scans de Table et les Scans d’Index Clusterisé puissent scanner tous les enregistrements d’une table, le Scan d’Index Clusterisé est généralement plus efficace grâce à son approche structurée et à ses capacités de traversée plus rapides. En comprenant ces différences, les administrateurs de bases de données et les développeurs peuvent prendre de meilleures décisions concernant les stratégies d’indexation et de récupération des données, ce qui conduit à une performance améliorée de leurs applications SQL Server.

Si vous souhaitez optimiser vos requêtes SQL et vos processus de récupération, envisagez d’implémenter des index clusterisés lorsque cela est approprié en fonction des besoins de votre base de données et de la nature de vos requêtes.