Come dice Remus, dipende dal carico di lavoro.
Voglio affrontare un aspetto fuorviante della risposta accettata però.
Per le query che eseguono una ricerca di uguaglianza su tutte le colonne dell'indice non vi sono differenze significative.
Il seguito crea due tabelle e le popola con dati identici. L'unica differenza è che uno ha i tasti ordinati dal più al meno selettivo e l'altro il contrario.
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;
Ora eseguendo una query su entrambe le tabelle ...
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 = '~';
... Entrambi usano una multa indice ed entrambi hanno lo stesso costo esatto.
L'arte ASCII nella risposta accettata non è in realtà la struttura degli indici. Le pagine di indice per Table1 sono rappresentate di seguito (fare clic sull'immagine per aprirla a schermo intero).
Le pagine dell'indice contengono righe contenenti l'intera chiave (in questo caso in realtà è stata aggiunta una colonna chiave aggiuntiva per l'identificatore di riga poiché l'indice non è stato dichiarato come univoco ma è possibile ignorare ulteriori informazioni al riguardo ).
Per la query sopra SQL Server non interessa la selettività delle colonne. Esegue una ricerca binaria della pagina principale e scopre che la chiave (PPP...,3,~ ) è >=(JJJ...,1,~ )e < (SSS...,3,~ )quindi dovrebbe leggere la pagina 1:118. Quindi effettua una ricerca binaria delle voci chiave in quella pagina e individua la pagina foglia su cui viaggiare.
La modifica dell'indice in ordine di selettività non influisce né sul numero previsto di confronti chiave dalla ricerca binaria né sul numero di pagine che devono essere esplorate per effettuare una ricerca dell'indice. Nella migliore delle ipotesi, potrebbe accelerare leggermente il confronto chiave stesso.
A volte, tuttavia, ordinare prima l'indice più selettivo avrà senso per altre query nel carico di lavoro.
Ad esempio, se il carico di lavoro contiene query di entrambi i seguenti moduli.
SELECT * ... WHERE MostSelective = 'P'
SELECT * ...WHERE Least = '~'
Gli indici sopra non riguardano nessuno dei due. MostSelectiveè abbastanza selettivo da rendere utile un piano con una ricerca e ricerche, ma la query Leastnon lo è.
Tuttavia, questo scenario (ricerca dell'indice non coprente su un sottoinsieme delle colonne principali di un indice composito) è solo una possibile classe di query che può essere aiutata da un indice. Se non cerchi mai da MostSelectivesolo o una combinazione di MostSelective, SecondMoste cerchi sempre da una combinazione di tutte e tre le colonne, questo vantaggio teorico è inutile per te.
Al contrario query come
SELECT MostSelective,
SecondMost,
Least
FROM Table2
WHERE Least = '~'
ORDER BY SecondMost,
MostSelective
Sarebbe aiutato dall'ordine inverso di quello comunemente prescritto - poiché copre la query, può supportare una ricerca e restituisce le righe nell'ordine desiderato per l'avvio.
Quindi questo è un consiglio spesso ripetuto, ma al massimo è un'euristica sul potenziale beneficio di altre query - e non è un sostituto per guardare effettivamente il tuo carico di lavoro.