Comme le dit Remus, cela dépend de votre charge de travail.
Je veux cependant aborder un aspect trompeur de la réponse acceptée.
Pour les requêtes qui exécutent une recherche d'égalité sur toutes les colonnes de l'index, il n'y a pas de différence significative.
Le tableau ci-dessous crée deux tableaux et les remplit avec des données identiques. La seule différence est que l'un a les clés classées du plus au moins sélectif et l'autre l'inverse.
CREATE TABLE Table1(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE TABLE Table2(MostSelective char(800), SecondMost TINYINT, Least CHAR(1), Filler CHAR(4000) null);
CREATE NONCLUSTERED INDEX MyINDX on Table1(MostSelective,SecondMost,Least);
CREATE NONCLUSTERED INDEX MyINDX2 on Table2(Least,SecondMost,MostSelective);
INSERT INTO Table1 (MostSelective, SecondMost, Least)
output inserted.* into Table2
SELECT TOP 26 REPLICATE(CHAR(number + 65),800), number/5, '~'
FROM master..spt_values
WHERE type = 'P' AND number >= 0
ORDER BY number;
Maintenant, faites une requête sur les deux tables ...
SELECT *
FROM Table1
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
SELECT *
FROM Table2
WHERE MostSelective = REPLICATE('P', 800)
AND SecondMost = 3
AND Least = '~';
... Les deux utilisent une amende indexée et les deux reçoivent exactement le même coût.
L'art ASCII dans la réponse acceptée n'est en fait pas la façon dont les index sont structurés. Les pages d'index de Table1 sont représentées ci-dessous (cliquez sur l'image pour l'ouvrir en taille réelle).
Les pages d'index contiennent des lignes contenant la clé entière (dans ce cas, il y a en fait une colonne clé supplémentaire ajoutée pour l'identificateur de ligne car l'index n'a pas été déclaré comme unique mais qui peut être ignoré, des informations supplémentaires à ce sujet peuvent être trouvées ici ).
Pour la requête ci-dessus, SQL Server ne se soucie pas de la sélectivité des colonnes. Il effectue une recherche binaire de la page racine et découvre que la clé (PPP...,3,~ ) est >=(JJJ...,1,~ )et < (SSS...,3,~ )doit donc lire la page 1:118. Il effectue ensuite une recherche binaire des entrées clés de cette page et localise la page feuille vers laquelle se déplacer.
La modification de l'index par ordre de sélectivité n'affecte ni le nombre attendu de comparaisons clés de la recherche binaire ni le nombre de pages à parcourir pour effectuer une recherche d'index. Au mieux, cela pourrait légèrement accélérer la comparaison clé elle-même.
Parfois, la commande de l'index le plus sélectif en premier aura du sens pour d'autres requêtes de votre charge de travail.
Par exemple, si la charge de travail contient des requêtes des deux formes suivantes.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Les index ci-dessus ne couvrent ni l'un ni l'autre. MostSelectiveest suffisamment sélectif pour faire un plan avec une recherche et des recherches utiles, mais la requête contre Leastne l'est pas.
Cependant, ce scénario (recherche d'index non couvrant sur un sous-ensemble de colonne (s) de tête d'un index composite) n'est qu'une classe de requête possible qui peut être aidée par un index. Si vous ne recherchez jamais par MostSelectivelui-même ou par une combinaison de MostSelective, SecondMostet toujours par une combinaison des trois colonnes, cet avantage théorique vous est inutile.
À l'inverse, des requêtes telles que
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Serait aidé en ayant l'ordre inverse de celui couramment prescrit - car il couvre la requête, peut prendre en charge une recherche et retourne les lignes dans l'ordre souhaité pour démarrer.
Il s'agit donc d'un conseil souvent répété, mais il s'agit tout au plus d'une heuristique sur les avantages potentiels d' autres requêtes - et cela ne remplace pas le fait d'examiner votre charge de travail.