Lorsque vous voulez la vitesse de récupération maximale et que les deux colonnes sont dans la jointure ou les conditions where, MAIS parfois la colonne a a une sélectivité plus élevée et parfois la colonne b a une sélectivité plus élevée, et vous souhaitez capitaliser sur ce fait à partir d'un index unique.
De plus, je pense que votre rapport taille des données / performances de la machine devrait être assez élevé et en même temps vous devrez (estimation) être prêt à appeler toute amélioration une nécessité (même si ce n'est que de quelques pourcentages).
Pourtant, l'expérience enseigne que les choses dépendent de nombreux facteurs; avec des RDBMS et des environnements d'application spécifiques, vous feriez mieux d'exécuter vos propres benchmarks.
EDIT : explications supplémentaires sur les index composites. de wikipedia
:
"L'ordre dans lequel les colonnes sont répertoriées dans la définition de l'index est important. Il est possible de récupérer un ensemble d'identifiants de ligne en utilisant uniquement la première colonne indexée. Cependant, il n'est ni possible ni efficace (sur la plupart des bases de données) pour récupérer l'ensemble des identificateurs de ligne en utilisant uniquement la deuxième colonne indexée ou plus.
Par exemple, imaginez un annuaire téléphonique organisé d'abord par ville, puis par nom de famille, puis par prénom. Si vous sont donnés la ville, vous pouvez facilement extraire la liste de tous les numéros de téléphone pour cette ville. Cependant, dans cet annuaire téléphonique, il serait très fastidieux de trouver tous les numéros de téléphone pour un nom de famille donné. Il faudrait chercher dans chaque ville section pour les entrées avec ce nom de famille."
Les explications de Wikipedia sont peut-être trop simplifiées, mais cela vous donne l'idée de base (comme les analogies vont garder à l'esprit que les annuaires téléphoniques ont généralement des index groupés et que ce ne serait pas votre index général de base de données).
En fonction de la taille de l'index par rapport à la taille de la structure de données par rapport à la mémoire disponible par rapport à la sélectivité sur la première colonne de l'index, il peut toujours être beaucoup moins coûteux d'utiliser un index mal ordonné que d'utiliser des analyses de table.
Ah, je viens de penser à une meilleure analogie avec un exemple que vous recherchezImaginez un beau manuel, il aurait une table des matières avec des chapitres et des sous-chapitres et le nombre de pages auxquelles ils se trouvent (qui est un index non groupé qui contient des pointeurs vers enregistrements de données - pages). Maintenant, imaginez que le manuel est sur la norme SQL-92, alors la plupart des termes de la table des matières seraient des termes SQL (maintenez cette hypothèse). Vous auriez également un autre index à la fin du livre qui répertorier tous les termes intéressants par ordre alphabétique (supposons avec les principaux noms de chapitre) et les numéros de page.
Pour une question telle que "Dites-moi tous les chapitres sous lesquels DISTINCT apparaît", vous utiliserez le deuxième index. (parce que la sélectivité du dernier champ est élevée)
Pour une question telle que "Dites-moi le nombre de termes qui apparaissent sous le premier chapitre", vous utiliserez la table des matières
Ainsi, pour des questions telles que « SELECT est-il décrit dans le chapitre DML ? » vous pouvez utiliser l'un ou l'autre des index. (parce que la sélectivité des deux champs est élevée) Cependant, si la table des matières de DML elle-même fait 3 pages et que l'entrée SELECT de l'index n'a que quinze lignes, vous irez probablement au second, et c'est un exemple de cas où vous bénéficiez des deux index.
Maintenant, si vous pensez que c'est trop tiré par les cheveux, prenez en considération une base de données de la bibliothèque numérisée du congrès. :)
Comme je l'ai déjà dit, toute la planification est bonne, mais à la fin, exécutez vos propres repères.
