Question

J'ai un index sur les colonnes A, B, C, D de la table T

J'ai une requête qui extrait de T avec A, B, C dans la clause WHERE.

L’index sera-t-il utilisé ou faudra-t-il un index séparé incluant uniquement A, B, C?

Était-ce utile?

La solution

David B a raison de vérifier le plan d'exécution pour vérifier que l'index est utilisé.

L'index sera-t-il utilisé ou faudra-t-il un index séparé comprenant uniquement A, B, C?

Pour répondre à cette dernière partie de la question, qui est selon moi le principal sujet sous-jacent (par opposition à la solution immédiate), il n'y a presque jamais de raison d'indexer un sous-ensemble de vos colonnes indexées. . Si votre indice est (A, B, C, D), un WHERE contre (A, B, C) donnera probablement un indice search , ce qui est la situation idéale - l'index comprend toutes les informations dont le moteur a besoin pour aller directement au jeu de résultats. Je crois que cela est vrai pour les types numériques et pour les tests d'égalité dans les types de chaîne, bien que cela puisse échouer avec LIKE '%'). D'autre part, si votre référence WHERE se référait uniquement à D, vous obtiendriez probablement un scan d'index, ce qui signifierait que le moteur SQL devrait analyser toutes les combinaisons de A, B et C, puis vérifiez si D répond à vos critères avant de décider d'ajouter ou non la ligne au jeu de résultats. Sur une table particulièrement volumineuse, lorsque je me suis retrouvé confronté à de nombreuses requêtes sur la colonne "D", j'ai ajouté un index supplémentaire pour D uniquement et constaté une amélioration des performances d'environ 90%.

Éditer: je devrais également recommander l'utilisation de l'Assistant Paramétrage du moteur de base de données dans SQL Management Studio. Il vous dira si votre table n'est pas indexée idéalement pour la requête que vous souhaitez exécuter.

Autres conseils

Cela dépend!

WHERE A like '%x%'
  and B = 1
  and C = 1
//
WHERE A = 1
  OR B = 1
  OR C = 1
//
WHERE DateAdd(dd, 1, A) = '2008-01-01'
  AND B = 1
  AND C = 1

Ils ne s'appuieront pas sur l'index, car il n'est pas utile.

Cliquez sur "Afficher le plan d'exécution estimé". pour confirmer l'utilisation potentielle d'index.

Dans les bases de données Oracle, il s'agit d'un Index composite . (Documents 12g mais valables pour les versions antérieures)

  

Les index composites peuvent accélérer l’extraction de données pour les instructions SELECT dans lesquelles la clause WHERE fait référence à la partie supérieure des colonnes de l’index composite. Par conséquent, l'ordre des colonnes utilisées dans la définition est important. En général, les colonnes les plus fréquemment utilisées sont les premières.

donc dans votre cas, oui. l'index serait / pourrait être utilisé. cela pourrait être vérifié à l'aide d'un plan d'explication.

si MS SQLSERVER est différent (et je suppose que cela pourrait être le cas), vous aurez besoin d’une nouvelle réponse.

Modifier: Mentionnons également qu’il ne fera que prendre en compte l’indice à utiliser .. cela ne signifie pas nécessairement qu’il l’utilisera.

Modifier2: Oracle 11g et les versions ultérieures disposent désormais d'une option lui permettant d'ignorer les colonnes d'un index donc une requête sur A, B et D peut toujours utiliser l'index

L’index sera utilisé, oui. Il est assez malin de savoir quels index produiront un plan de requête plus optimal, et cela ne devrait poser aucun problème.

Comme pour ce genre de chose, ne vous fiez pas à ma parole, comparez-la. Créez une table, remplissez-la avec des données représentatives, interrogez-la, indexez-la et interrogez-la à nouveau.

Le fait que l'index contienne une colonne qui n'est pas utilisée dans votre requête n'empêchera pas son utilisation.

Cela ne veut pas dire que il sera utilisé , il peut être ignoré pour une raison différente (peut-être parce qu'un ou plusieurs autres index sont plus utiles).

Comme toujours, examinez le plan d'exécution estimé pour voir ce qui va probablement arriver.

Commencez par la recherche simple d'égalité (WHERE A = 1 et B = 'Red' et C = 287). Oui, l'index sera (très probablement) utilisé. L’indice sera d’abord utilisé pour aider l’optimiseur " deviner " le nombre de lignes qui correspondront à la sélection, puis en second lieu, pour accéder réellement à ces lignes.

En réponse au commentaire de David B à propos du "like" prédicat, SQLServer peut toujours utiliser l'index, cela dépend de ce que vous sélectionnez. Par exemple, si vous sélectionnez un nombre (*), SQLServer analysera probablement l'index et comptera les occurrences correspondant à la clause where, car l'index est plus petit et nécessitera moins d'IO à analyser. Et il peut décider de le faire même si vous sélectionnez des colonnes dans la table de base, en fonction de la sélectivité de l'index pour SQLServer.

Voici un autre message "cela dépend" répondez ... cela dépend aussi de la taille de votre table ...

Je suis d'accord avec toutes les personnes qui ont mentionné la vérification du plan d'exécution pour vérifier si votre index est utilisé ou non.

Voici quelques articles sur la lecture d'un plan d'exécution que vous devriez trouver utiles:

http://www.sqlservercentral.com/articles/Administering/executionplans/ 1345 / http://www.codeproject.com/KB/database/ sql-tuning-tutorial-1.aspx

Il existe également un bon article sur les recherches et les analyses que je recommanderais: http://blogs.msdn.com/craigfr/archive/ 2006/06/26 / 647852.aspx

Il existe un journal de bons articles sur le blog de Craig Freedman, en voici un autre que vous devriez trouver utile. Cet article traite de certains facteurs utilisés par SQL Server pour déterminer l’index à utiliser ...

http://blogs.msdn.com/craigfr /archive/2006/07/13/664902.aspx

Prenez soin de vous! Jeff

De manière générale, oui, toutes les bases de données modernes sont assez intelligentes pour le faire. Il existe des exceptions, par exemple, si les statistiques de la table montrent que le volume de données qu'il contient est suffisamment petit pour qu'une table complète lue soit plus efficace, alors l'index sera actualisé, mais en règle générale, vous pouvez vous y fier le cas échéant.

Par conséquent, vous pouvez en tirer parti lors de la conception de vos index. Supposons, par exemple, une table contenant A, B, C comme valeurs de clé et les colonnes Y et Z contenant des données qui, je le sais, seront extraites souvent par les instructions

SELECT Y FROM table WHERE A = alpha and B = beta and C = gamma 

SELECT Z FROM table WHERE A = alpha and B = beta and C = gamma 

Le je vais généralement créer un index sur A, B, C, X, Z - en supposant que X et Z sont des champs raisonnablement petits. La raison en est que je sais que le chemin d'accès dans les instructions ci-dessus utilisera l'index, et comme les données que je veux récupérer sont déjà dans l'index read , aucune lecture séparée du bloc de données nécessaire pour récupérer les données de la table elle-même sera nécessaire. Cette stratégie peut considérablement accélérer la récupération des données dans certaines circonstances. Bien sûr, vous payez pour cela en coûts de mise à jour et en espace disque. Vous devez donc comprendre ce que fait votre base de données avant de l’appliquer, mais comme dans la plupart des bases de données, les écritures sont nettement plus nombreuses que les écritures.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top