Cela importe principalement lorsqu'il est utilisé avec des index composites :
CREATE INDEX ix_index ON mytable (col1, col2 DESC);
peut être utilisé pour :
SELECT *
FROM mytable
ORDER BY
col1, col2 DESC
ou :
SELECT *
FROM mytable
ORDER BY
col1 DESC, col2
, mais pas pour :
SELECT *
FROM mytable
ORDER BY
col1, col2
Un index sur une seule colonne peut être utilisé efficacement pour trier dans les deux sens.
Voir l'article sur mon blog pour plus de détails :
- Indices décroissants
Mise à jour :
En fait, cela peut avoir de l'importance même pour un seul index de colonne, même si ce n'est pas si évident.
Imaginez un index sur une colonne d'une table clusterisée :
CREATE TABLE mytable (
pk INT NOT NULL PRIMARY KEY,
col1 INT NOT NULL
)
CREATE INDEX ix_mytable_col1 ON mytable (col1)
L'index sur col1 conserve les valeurs ordonnées de col1 ainsi que les références aux lignes.
Puisque la table est groupée, les références aux lignes sont en fait les valeurs du pk . Ils sont également classés dans chaque valeur de col1 .
Cela signifie que les feuilles de l'index sont en fait ordonnées sur (col1, pk) , et cette requête :
SELECT col1, pk
FROM mytable
ORDER BY
col1, pk
n'a pas besoin d'être trié.
Si nous créons l'index comme suit :
CREATE INDEX ix_mytable_col1_desc ON mytable (col1 DESC)
, puis les valeurs de col1 seront triés par ordre décroissant, mais les valeurs de pk dans chaque valeur de col1 seront triés par ordre croissant.
Cela signifie que la requête suivante :
SELECT col1, pk
FROM mytable
ORDER BY
col1, pk DESC
peut être servi par ix_mytable_col1_desc mais pas par ix_mytable_col1 .
Autrement dit, les colonnes qui constituent un CLUSTERED INDEX sur n'importe quelle table sont toujours les colonnes de fin de tout autre index sur cette table.
