Plans SQL Server: différence entre l'analyse d'index et la recherche d'index
Dans un plan d'exécution SQL Server, quelle est la différence entre une analyse d'index et une recherche d'index
Je suis sur SQL Server 2005.
Une analyse d'index est l'endroit où le serveur SQL lit l'intégralité de l'index à la recherche de correspondances - le temps que cela prend est proportionnel à la taille de l'index.
Une recherche d'index est l'endroit où SQL Server utilise la structure b-tree de l'index pour rechercher directement les enregistrements correspondants (voir http://mattfleming.com/node/192 pour une idée de la façon dont cela fonctionne) - le temps nécessaire est uniquement proportionnel au nombre d'enregistrements correspondants.
- En général, une recherche d'index est préférable à une analyse d'index (lorsque le nombre d'enregistrements correspondants est beaucoup plus faible que le nombre total d'enregistrements), car le temps nécessaire pour effectuer une recherche d'index est constant quel que soit le nombre total d'enregistrements dans votre table.
- Notez cependant que dans certaines situations, un balayage d'index peut être plus rapide qu'une recherche d'index (parfois considérablement plus rapide) - généralement lorsque la table est très petite, ou lorsque un grand pourcentage des enregistrements correspondent au prédicat.
La règle de base à suivre est que les analyses sont mauvaises, les recherches sont bonnes.
Scan d'index
Lorsque SQL Server effectue une analyse, il charge l'objet qu'il veut lire du disque dans la mémoire, puis lit cet objet de haut en bas à la recherche des enregistrements dont il a besoin.
Recherche d'index
Lorsque SQL Server effectue une recherche, il sait où se trouvent les données dans l'index, il charge donc l'index à partir du disque, va directement à la partie de l'index dont il a besoin et lit où se trouvent les données dont il a besoin. . Il s'agit évidemment d'une opération beaucoup plus efficace qu'une analyse, car SQL sait déjà où se trouvent les données qu'il recherche.
Comment puis-je modifier un plan d'exécution pour utiliser une recherche au lieu d'une analyse?
Lorsque SQL Server recherche vos données, l'une des choses les plus importantes qui fera passer SQL Server d'une recherche à une analyse est probablement lorsque certaines des colonnes que vous recherchez ne sont pas incluses dans l'index que vous souhaitez qu'elles utilisent. Le plus souvent, cela obligera SQL Server à effectuer une analyse d'index en cluster, car l'index en cluster contient toutes les colonnes de la table. C'est l'une des principales raisons (à mon avis du moins) que nous avons maintenant la possibilité d'INCLURE des colonnes dans un index, sans ajouter ces colonnes aux colonnes indexées de l'index. En incluant les colonnes supplémentaires dans l'index, nous augmentons la taille de l'index, mais nous permettons à SQL Server de lire l'index, sans avoir à revenir à l'index cluster ou à la table elle-même pour obtenir ces valeurs.
Références
Pour plus d'informations sur les spécificités de chacun de ces opérateurs dans un plan d'exécution SQL Server, voir ....
Analyses vs recherches
Scan d'index:
Puisqu'une analyse touche chaque ligne du tableau, qu'elle soit éligible ou non, le coût est proportionnel au nombre total de lignes du tableau. Ainsi, une analyse est une stratégie efficace si la table est petite ou si la plupart des lignes se qualifient pour le prédicat.
Recherche d'index:
Étant donné qu'une recherche ne touche que les lignes qualifiées et les pages qui contiennent ces lignes éligibles, le coût est proportionnel au nombre de lignes et de pages éligibles plutôt qu'au nombre total de lignes du tableau.
La numérisation d'index n'est rien d'autre qu'une numérisation sur les pages de données de la première à la dernière page. S'il y a un index sur une table et si la requête touche une plus grande quantité de données, cela signifie que la requête récupère plus de 50% ou 90% des données, puis l'optimiseur analysera simplement toutes les pages de données pour récupérer les lignes de données. S'il n'y a pas d'index, vous pouvez voir une analyse de table (analyse d'index) dans le plan d'exécution.
Les recherches d'index sont généralement préférées pour les requêtes hautement sélectives. Cela signifie que la requête demande simplement un nombre inférieur de lignes ou récupère simplement les 10 autres (certains documents indiquent 15%) des lignes du tableau.
En général, l'optimiseur de requêtes essaie d'utiliser une recherche d'index, ce qui signifie que l'optimiseur a trouvé un index utile pour récupérer le jeu d'enregistrements. Mais s'il n'est pas en mesure de le faire parce qu'il n'y a pas d'index ou d'index utiles sur la table, SQL Server doit analyser tous les enregistrements qui satisfont à la condition de requête.
Différence entre un scan et une recherche?
Une analyse renvoie l'intégralité de la table ou de l'index. Une recherche renvoie efficacement des lignes d'une ou plusieurs plages d'un index en fonction d'un prédicat. Par exemple, considérez la requête suivante:
select OrderDate from Orders where OrderKey = 2
Numérisation
Avec une analyse, nous lisons chaque ligne du tableau des commandes, évaluons le prédicat "où OrderKey = 2" et, si le prédicat est vrai (c'est-à-dire si la ligne se qualifie), renvoyons la ligne. Dans ce cas, nous appelons le prédicat un prédicat "résiduel". Pour maximiser les performances, nous évaluons chaque fois que possible le prédicat résiduel dans l'analyse. Cependant, si le prédicat est trop cher, nous pouvons l'évaluer dans un itérateur de filtre séparé. Le prédicat résiduel apparaît dans le texte showplan avec le mot-clé WHERE ou dans XML showplan avec la balise.
Voici le plan de présentation du texte (légèrement modifié pour plus de brièveté) pour cette requête à l'aide d'une analyse:
| –Table Scan (OBJET: ([COMMANDES]), OERE: ([ORDERKEY] = (2))))
La figure suivante illustre l'analyse:
Puisqu'une analyse touche chaque ligne du tableau, qu'elle soit éligible ou non, le coût est proportionnel au nombre total de lignes du tableau. Ainsi, une analyse est une stratégie efficace si la table est petite ou si la plupart des lignes se qualifient pour le prédicat. Cependant, si la table est grande et si la plupart des lignes ne sont pas qualifiées, nous touchons beaucoup plus de pages et de lignes et effectuons beaucoup plus d'E/S que nécessaire.
Chercher
Pour revenir à l'exemple, si nous avons un index sur OrderKey, une recherche peut être un meilleur plan. Avec une recherche, nous utilisons l'index pour naviguer directement vers les lignes qui satisfont le prédicat. Dans ce cas, nous appelons le prédicat un prédicat de "recherche". Dans la plupart des cas, nous n'avons pas besoin de réévaluer le prédicat de recherche comme prédicat résiduel; l'index garantit que la recherche ne renvoie que les lignes qualifiées. Le prédicat de recherche apparaît dans le texte showplan avec le mot clé SEEK ou dans XML showplan avec la balise.
Voici le plan de présentation du texte pour la même requête à l'aide d'une recherche:
| –Index Seek (OBJET: ([ORDERS]. [OKEY_IDX]), CHERCHER: ([ORDERKEY] = (2)) ORDERED FORWARD)
La figure suivante illustre la recherche:
Étant donné qu'une recherche ne touche que les lignes qualifiées et les pages qui contiennent ces lignes éligibles, le coût est proportionnel au nombre de lignes et de pages éligibles plutôt qu'au nombre total de lignes du tableau. Ainsi, une recherche est généralement une stratégie plus efficace si nous avons un prédicat de recherche hautement sélectif; c'est-à-dire, si nous avons un prédicat de recherche qui élimine une grande partie de la table.
Une note sur showplan
Dans showplan, nous faisons la distinction entre les analyses et les recherches ainsi qu'entre les analyses sur les tas (un objet sans index), les index cluster et les index non cluster. Le tableau suivant montre toutes les combinaisons valides:
https://blogs.msdn.Microsoft.com/craigfr/tag/scans-and-seeks/
Réponse courte:
Balayage d'index: touchez toutes les lignes sauf certaines colonnes.
Recherche d'index: touchez certaines lignes et certaines colonnes.
Avec une analyse d'index, toutes les lignes de l'index sont analysées pour trouver une ligne correspondante. Cela peut être efficace pour les petites tables. Avec une recherche d'index, il suffit de toucher les lignes qui répondent réellement aux critères et est donc généralement plus performant
Une analyse d'index se produit lorsque la définition d'index ne peut pas trouver sur une seule ligne pour satisfaire les prédicats de recherche. Dans ce cas, SQL Server doit scanner plusieurs pages pour trouver une plage de lignes qui satisfont les prédicats de recherche.
Dans le cas d'une recherche d'index, SQL Server recherche une seule ligne correspondant aux prédicats de recherche à l'aide de la définition index.
Les recherches d'index sont meilleures et plus efficaces.
Un scan touche chaque ligne du tableau même si c'est ce que vous recherchez ou non
Une recherche ne regarde que les lignes que vous recherchez.
Les recherches sont toujours meilleures que les analyses car elles sont plus efficaces dans la façon dont elles recherchent les données.
Une bonne explication peut être trouvée ici