Que sont les index de couverture et les requêtes couvertes dans SQL Server?

Question

Pouvez-vous expliquer les concepts et les relations entre les index de couverture et les requêtes couvertes dans Microsoft SQL Server?

Answer 1

Un index de couverture est un index qui peut satisfaire toutes les colonnes demandées dans une requête sans effectuer de recherche supplémentaire dans l'index en cluster.

Il n’existe pas de requête couvrant.

Consultez cet article de Simple-Talk: Utilisation des index de couverture pour améliorer les performances des requêtes .

Answer 2

Si toutes les colonnes demandées dans la liste de requêtes select sont disponibles dans l'index , le moteur de requête n'a pas pour rechercher à nouveau la table, ce qui peut considérablement augmenter les performances de la requête. Toutes les colonnes demandées étant disponibles dans l'index, l'index couvre la requête. La requête s'appelle donc une requête de couverture et l’index est un index de couverture.

Un index clusterisé peut toujours couvrir une requête si les colonnes de la liste de sélection appartiennent à la même table.

Les liens suivants peuvent être utiles si vous débutez en indexant des concepts:

• Excellente vidéo sur les avantages et inconvénients de l'index et couvrant requêtes et index.
• Index dans SQL Server

Answer 3

Un index de couverture est un index non clusterisé . Les index clusterisés et non clusterisés utilisent tous deux la structure de données B-Tree pour améliorer la recherche de données. La différence est que dans les feuilles d'un index clusterisé, un enregistrement entier (une ligne) est stocké physiquement à cet emplacement !, mais ce n'est pas le cas. case pour les index non clusterisés. Les exemples suivants l’illustrent:

Exemple: j'ai une table avec trois colonnes: ID, Fname et Lname.

Toutefois, pour un index non clusterisé, il existe deux possibilités: soit la table a déjà un index clusterisé, soit elle n'en possède pas:

Comme le montrent les deux diagrammes, ces index non clusterisés n'offrent pas de bonnes performances, car ils ne peuvent pas trouver la valeur préférée (c'est-à-dire Lname) uniquement à partir du B-Tree. Au lieu de cela, ils doivent effectuer une étape supplémentaire de recherche (recherche de clé ou de RID) pour trouver la valeur de Lname. Et, c'est ici que l'index couvert apparaît à l'écran. Ici, l'index non groupé sur ID couvre la valeur de Lname juste à côté dans les feuilles du B-Tree et il n'y a aucun besoin pour tout type de recherche plus.

Answer 4

Une requête couverte est une requête dans laquelle toutes les colonnes du jeu de résultats de la requête sont extraites d'index non clusterisés.

Une requête est transformée en une requête couverte par la disposition judicieuse des index.

Une requête couverte est souvent plus performante qu'une requête non couverte en partie parce que les index non clusterisés ont plus de lignes par page que les index clusterisés ou les index de segment de mémoire; moins de pages doivent donc être mises en mémoire pour satisfaire la requête. . Ils ont plus de lignes par page car seule une partie de la ligne de tableau fait partie de la ligne d’index.

Un index couvrant est un index utilisé dans une requête couverte. Il n’existe pas d’indice qui soit, en soi, un indice de couverture. Un index peut être un index couvrant la requête A, sans être en même temps un index couvrant la requête B.

Answer 5

Voici un article dans devx.com qui dit:

  

Création d'un index non clusterisé contenant toutes les colonnes utilisées dans une requête SQL, technique appelée index couvrant

Je ne peux que supposer qu'une requête couverte est une requête dont l'index couvre toutes les colonnes de son jeu d'enregistrements renvoyé. Une mise en garde - l'index et la requête doivent être construits de manière à permettre au serveur SQL de déduire de la requête que l'index est utile.

Par exemple, une jointure de table sur elle-même peut ne pas bénéficier d'un tel index (selon l'intelligence du planificateur d'exécution de requêtes SQL):

PersonID ParentID Name
1        NULL     Abe
2        NULL     Bob
3        1        Carl
4        2        Dave

Supposons qu'il existe un index sur PersonID, ParentID, Name - il s'agirait d'un index couvrant pour une requête telle que:

SELECT PersonID, ParentID, Name FROM MyTable

Mais une requête comme celle-ci:

SELECT PersonID, Name FROM MyTable LEFT JOIN MyTable T ON T.PersonID=MyTable.ParentID

Ne serait probablement pas aussi bénéfique, même si toutes les colonnes sont dans l'index. Pourquoi? Parce que vous ne dites pas vraiment que vous voulez utiliser le triple index de PersonID, ParentID, Name .

Au lieu de cela, vous créez une condition basée sur deux colonnes - PersonID et ParentID (sans laisser de code Nom ), puis vous ' Re demande tous les enregistrements, avec les colonnes PersonID, Name . En fait, selon l’implémentation, l’indice pourrait aider cette dernière partie. Mais pour la première partie, il vaut mieux avoir d’autres index.

Answer 6

Une requête de couverture porte sur la correspondance de tous les prédicats à l'aide des index des tables sous-jacentes.

Il s’agit du premier pas vers l’amélioration des performances du sql considéré.

Answer 7

un index de couverture est celui qui donne toutes les colonnes requises et dans lequel le serveur SQL n'a pas à revenir à l'index en cluster pour trouver une colonne. Ceci est réalisé en utilisant un index non-cluster et en utilisant l'option INCLUDE pour couvrir les colonnes. Les colonnes sans clé ne peuvent être incluses que dans des index non clusterisés. Les colonnes ne peuvent pas être définies à la fois dans la colonne clé et dans la liste INCLUDE. Les noms de colonnes ne peuvent pas être répétés dans la liste INCLUDE. Les colonnes non-clés ne peuvent être supprimées d'une table qu'après que l'index non-clé est d'abord supprimé. Voir les détails ici

Answer 8

Lorsque je me suis simplement rappelé qu'un index clusterisé se composait d'une liste de toutes les colonnes ordonnée par clé et ordonnée par clé, de toutes les colonnes de la table définie, les lumières se sont allumées pour moi. Le mot "groupe" désigne alors le fait qu'il existe un "groupe". de toutes les colonnes, comme une grappe de poissons dans ce "point chaud". S'il n'y a pas d'index couvrant la colonne contenant la valeur recherchée (le côté droit de l'équation), le plan d'exécution utilise une recherche d'index clusterisé dans la représentation de la colonne demandée par l'index clusterisé, car il ne trouve la colonne demandée dans aucune autre. " couvrant " indice. L'absence entraînera un opérateur de recherche d'index clusterisé dans le plan d'exécution proposé, dans lequel la valeur recherchée se trouve dans une colonne de la liste ordonnée représentée par l'index clusterisé.

Une solution consiste donc à créer un index non clusterisé comportant la colonne contenant la valeur demandée à l'intérieur de l'index. De cette manière, il n'est pas nécessaire de faire référence à l'index clusterisé, et l'optimiseur devrait être capable de lier cet index au plan d'exécution sans indication. Cependant, si un prédicat nomme la clé de clustering à colonne unique et un argument correspondant à une valeur scalaire sur la clé de clustering, l'opérateur de recherche d'index clusterisé sera toujours utilisé, même s'il existe déjà un index de couverture dans une seconde colonne de la colonne. table sans index.