2009-09-23 3 views
1

Par exemple:Les indices de couverture remplacent-ils en toute sécurité les plus petits indices de couverture?

Given columns A,B,C,D, 

IX_A is an index on 'A' 

IX_AB is a covering index on 'AB' 

IX_A peut être retiré en toute sécurité, car il est redondant: IX_AB sera utilisé à sa place. Je veux savoir si ce généralise:

Si j'ai:

IX_AB 
IX_ABC 
IX_ABCD 

et ainsi de suite,

peut les indices moins être encore supprimés en toute sécurité? En d'autres termes, IX_ABC rend-il IX_AB redondant, et IX_ABCD rend-il IX_AB et IX_ABC redondants?

Répondre

3

En général, et cela varie d'un serveur à l'autre, un index de couverture couvrira les plus petites sélections de l'index. Donc, si vous avez un index qui couvre a, b, c, cela vous donne automatiquement un index qui couvre a, et a, b.

Vous n'êtes pas certain d'avoir, par exemple, un indice de recouvrement de b, c.

+0

Vous * certainement * n'aura pas un indice de couverture de BC. Mais +1 - tout SGBD qui n'a pas utilisé AB_IDX pour rechercher A serait très pauvre. – paxdiablo

+0

Il me semble me souvenir de certains SGBD plus petits qui ont accordé B, C sur un indice couvrant A, B, C. Cependant, ce n'est certainement pas le cas pour SQL Server ou Oracle. – Randolpho

+0

Je pense que vous parlez peut-être des recherches d'index par rapport aux analyses d'index. Une recherche d'index sera effectuée si les colonnes principales sont utilisées dans la requête. Un balayage d'index (qui va directement aux feuilles) sera utilisé si les colonnes sont dans l'index, mais pas les colonnes principales. – Logicalmind

2

Oui, pour la plupart. Cependant, IX_ABCD n'est pas très utile en remplacement, disons, de IX_BCD. Il y a toutefois une mise en garde: les index peuvent encore nécessiter des lectures de disque, donc si C et D explose la taille de l'index, il y aura une certaine inefficacité dans la recherche de A, B dans IX_ABCD qui ne se produirait pas dans IX_AB.

Cependant, cette différence est probablement compensée par l'augmentation des performances supplémentaires de la maintenance de IX_AB séparément.

+0

Re "cette différence est probablement plus importante": cela dépend de votre rapport lecture/écriture. Dans un cas extrême, une table statique n'a aucun impact sur les performances en raison de plusieurs index. Mais +1 pour le disque lit - c'est un bon point. – paxdiablo

1

L'important est les colonnes principales de l'index. Si vous avez l'index IX_ABCD les requêtes suivantes utiliseront l'index:

select * from table où A = 1

select * from table où A = 1 et B = 1

select * from table où A = 1 et B = 1 et C = 1

Cependant, ce qui suit sera très probablement utilise pas l'index (au moins pas comment vous aviez l'intention):

select * from table où B = 1

select * from table où C = 1

select * from table où B = 1 et C = 1

L'important est que les colonnes principales sont utilisées. Par conséquent, l'ordre des colonnes lors de la création de l'index est important.

0

Pas nécessairement. S'il est vrai qu'un index sur (A, B, C) peut être utilisé pour un prédicat de filtrage sur A ou une demande d'ordre sur A ou une condition de jointure sur A, cela ne signifie pas nécessairement que l'index (A) seul est inutile .Si l'index sur (A, B, C) est considérablement plus grand que (A), alors un balayage de plage sur A seul économisera des E/S significatives car il devrait lire moins de pages (indice plus étroit).

Je pense que ce serait l'exception plutôt que la règle. En général, il est sûr de supprimer un index sur A si un autre sur (A, B) existe. Notez qu'un index sur (A, B) ne satisfait à aucun filtrage sur B donc, est sûr de ne supprimer que si les colonnes les plus à gauche sont les mêmes. Certaines bases de données ont des opérateurs 'skip-scan' qui peuvent utiliser un index sur (A, B) pour chercher B, mais c'est un cas de frontière très étroit.

0

Il est toujours préférable de ne rien présumer des composants internes du moteur de base de données et de vérifier réellement les plans de requête utilisés.

Questions connexes