La réduction Lookups clés
https://dba.stackexchange.com/questions/9124
-
16-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'utilise SQL Server, et je suis à la recherche de près le concept de recherche de clé,
Donc, si vous avez une recherche clé, vous pouvez créer un index avec les colonnes include pour couvrir les colonnes non-index que vous avez dans l'instruction select.
Par exemple,
SELECT ID, FirstName FROM OneIndex WHERE City = 'Las Vegas'
GO
Cet indice comprend une recherche de clé,
CREATE NONCLUSTERED INDEX [IX_OneIndex_City] ON [dbo].[OneIndex]
(
[City] ASC
) ON [PRIMARY]
GO
Mais celui-ci supprimera la recherche de clé,
CREATE NONCLUSTERED INDEX [IX_OneIndex_Include] ON [dbo].[OneIndex]
(
City
) INCLUDE (FirstName,ID) ON [PRIMARY]
GO
Je veux dire combien d'impact cela aura-t sur la performance? La recherche de clé a un coût de l'opérateur de 0,295969 (99%), mais qu'est-ce que cela signifie vraiment?
Comment savez-vous qui ont besoin du deuxième indice là-bas, et à quel moment devient-il le cas que vous essayez d'ajouter trop d'index et il est pas la peine?
Il me semble que certaines requêtes peuvent inclure des analyses d'index, recherche de clé, et semblent encore effectuer très rapidement.
La solution
Imaginez la compagnie de téléphone a une liste de numéros de téléphone, y compris le client qui est, où ils vivent, ce que leur numéro de facturation est, et ainsi de suite. La clé primaire pourrait être le numéro de téléphone.
Ils vous donnent les pages blanches. C'est comme un index non ordonnés en clusters, qui classés par ordre alphabétique, y compris les colonnes comme l'adresse.
Si vous voulez trouver tous les Farleys dans le livre, et sont intéressés par leurs adresses, puis les pages blanches est tout ce dont vous avez besoin. Vous pouvez rapidement rechercher la Farleys (trouver les Fs, et ainsi de suite), et vous avez toutes les informations dont vous avez besoin.
Mais si vous voulez leur numéro de facturation, alors vous devez faire une recherche. Vous pouvez rapidement trouver tous les numéros de téléphone du Farleys, mais vous devez prendre chacun d'entre eux (des centaines) et faire une autre SEEK (recherche) dans l'index (en cluster), celui qui est commandé par le numéro de téléphone. Chacun d'entre eux est à peu près le même coût que le cherchent à trouver les Farleys, ce qui rend vos ordres d'exécution de la requête de grandeur pire.
Et il y a un seuil. À un certain moment, la base de données réalisera qu'il est plus rapide que de passer par toutes les pages de l'index ordonné en clusters, en vérifiant chaque enregistrement pour voir si elle est d'intérêt.
Sérieusement - se débarrasser de Lookups. Vos questions pourraient être rapide maintenant, mais ne sera probablement pas l'échelle.
Autres conseils
Historique
Dans le pire des cas , une requête contenant une recherche doit aller au stockage physique pour les lignes qui nécessitent des données de la colonne ne sont pas couvertes par l'indice nonclustered. Dans le pire des pires cas, chaque recherche exigera une E / S séparé, et l'exécution devra attendre la valeur de cette ligne unique de données pour revenir avant de poursuivre. Ce scénario a généralement des conséquences graves de performance si la recherche doit traiter une significative nombre de lignes.
C'est pourquoi les recherches obtenir une si mauvaise presse. D'autre part, considèrent que la possibilité de faire des recherches a été introduit dans SQL Server 2000. Dans SQL Server 7.0 le processeur de requête ne peut utiliser un index non cluster si elle contenait tous les informations nécessaires pour satisfaire la requête ; dans tous les autres cas, il a dû les données d'accès via un index ordonné en clusters (si elle est présente, ou une analyse en tas autrement). Si étaient toujours si lookups très mauvais, SQL Server serait sûrement jamais les introduit.
Dans SQL Server 2000+ alors, où nous avons un index non cluster qui fournit des commandes utiles et / ou (la plupart) les colonnes requises par une requête, et où le nombre de consultations est susceptible d'être relativement faible, en utilisant la nonclustered index et effectuer une nombre limité de recherches sur la table de base est susceptible d'être la méthode d'accès le moins cher disponible (si un entièrement couvrant indice nonclustered pourrait être moins cher encore, bien sûr).
Dans de nombreux cas, il est juste pas pratique pour créer autant d'index non-cluster qui serait nécessaire pour éviter le balayage de la table de base pour toutes les requêtes communes. L'une des raisons pourrait être que la performance de INSERT/UPDATE/DELETE/MERGE est plus important que la vitesse interrogation (rappelez-vous que les opérations de modification de données doivent également maintenir tous les index non ordonnés en clusters concernés). Une autre raison pourrait être l'espace; chaque index non cluster représente une copie d'un sous-ensemble des colonnes de la table de base (ou expressions s'y rapportant) juste triées différemment. Plus des copies du moyen de données plus d'espace de stockage, et plus de choses en compétition pour l'espace dans la mémoire en cache de données SQL Server.
D'autres fois, nous pouvons créer quelques indices supplémentaires (peut-être filtrés dans SQL Server 2008+) avec suffisamment de colonnes de INCLUDE juste pour satisfaire la grande majorité des requêtes de performance critiques, sans compromettre les performances de modification des données trop, et sans utiliser trop d'espace disque supplémentaire. Équilibre entre les considérations concurrentes est ce qui rend plus l'art de réglage de l'index de la science.
Coût
Vous demandez ce que le coût de 99% pour l'opérateur recherche vraiment signifie dans le plan de requête. La composante des coûts de l'optimiseur de requête produit un estimée coût de cette opération est de 99% du total estimée pour la requête. Le nombre lui-même (0,29) ne signifie pas beaucoup du tout; à toutes fins pratiques, vous devriez considérer comme un numéro d'unité moins utilisé en interne par l'optimiseur lorsque l'on compare les stratégies alternatives pour cette requête spécifique.
Le coût estimé ne tient pas compte de votre matériel, la configuration, les besoins d'application, ou bien de toute autre chose. Le modèle de coût utilisé par l'optimiseur comprend un nombre important de heuristiques et des hypothèses simplificatrices que se produire pour produire des plans raisonnables la plupart du temps, pour la plupart des requêtes, sur la plupart des matériels. Cela ne veut pas dire qu'il n'y a pas corrélation entre les opérateurs à coût élevé dans les plans et la performance; plutôt le lien est souvent beaucoup plus faible que prévu couramment. Par tous les moyens de vérifier les raisons pour les opérateurs de plan de haut coût estimé en premier lieu, mais ne pas traiter l'information comme autre chose qu'une estimation très probablement erronée.
Impact
Je veux aussi mentionner quelques facteurs qui peuvent atténuer l'impact des recherches. Tout d'abord, je l'ai mentionné dès le début que le pire des cas, implique ligne par ligne E / S physiques . ce will faut éviter, évidemment, si les pages de données (index cluster ou tas) nécessaires pour satisfaire les recherches sont déjà en mémoire (cache de données). Si tel est le cas, la différence de temps d'exécution entre un plan avec une recherche par rapport à un indice de recouvrement peut bien être incommensurable. Même lorsque les E / S physique est nécessaire, si le nombre de lectures est faible, vous pouvez toujours pas de soins. (Comment les pages de données susceptibles d'une table doivent être dans le cache de données dépend de nombreux facteurs, et seront spécifiques à votre matériel et les circonstances).
Si plus qu'il faut un peu d'E / S physiques, l'impact des recherches peut encore être réduit par des optimisations présentes dans le plan de requête. Si SQL Server attend le nombre de consultations soit significatif, il peut choisir de trier les lignes explicitement entrant dans les jointure à boucles imbriquées conduisant la recherche dans l'ordre des touches non-cluster. Cette lecture séquentielle favorise réordonnancement de l'indice nonclustered, qui peut être beaucoup plus rapide que très E / S aléatoires sur votre matériel.
Avec ou sans tri explicite, les boucles imbriquées join conduisant la recherche peut avoir le WithOrderedPrefetch ou WithUnorderedPrefetch attributs présents. Dans les deux cas, le moteur d'exécution de la requête « regarde vers l'avenir » dans le flux de clé d'index et entraînant les problèmes lookups lecture anticipée lit. L'idée est de problème asynchrone demandes de lecture à I / système S pour les pages de données qui seront nécessaires rapidement, de sorte que le temps de la recherche a besoin d'une page de données, il est déjà présent dans la mémoire.
Dans des conditions idéales (faible fragmentation, bon plan de recherche, de haute performance I / système O) le mécanisme de lecture anticipée pourrait bien être assez rapide pour éviter même de grands plans de requête parallèle de toujours en attente sur les E / S complète. Cela est particulièrement vrai dans Enterprise Edition, qui peut émettre de très grandes demandes d'E / S unique (jusqu'à 2 Mo par demande si ma mémoire est bonne). D'autre part, dans des conditions moins qu'idéales (plus normal!), Votre requête peut souffrir horriblement car il attend sur longues files d'attente d'E / S, ou ne conduire le système d'E / S assez dur. La pire performance de cas de clés peut être lookups très pauvre.
Résumé
En résumé, vous généralement veulent éviter lookups où il est logique de le faire . Pour les petites requêtes (qui vont rester petit), vous pouvez décider que les frais généraux des indices supplémentaires (espace et maintenance) ne se justifie pas, en raison du poids donné aux besoins plus larges du système et de ses utilisateurs.
En fin de compte cela fait partie de l'art et la science qui est le développement et l'administration base de données.
