Quand utiliser un indice de couverture, un indice composite et indices colonnaires uniques

Question

Disons que je le tableau suivant dans SQL Server 2008:

ProfileID int   //identity; index: unique, primary key, clustered 
ClientID int 
RegionID int 
ProfileName nvarchar(50) 

Colonnes 2 et 3 lien vers leurs tables respectives via des relations étrangères.

Disons que ma requête la plus commune est la suivante:

SELECT ProfileID, ProfileName 
FROM Profiles 
WHERE ClientID = ? AND RegionID = ? 
ORDER BY ProfileName 

Quel système d'indexation est le mieux adapté? Si je mets un index de recouvrement sur (ProfileID, ProfileName), alors cela tue l'index cluster par défaut car les index de couverture doivent être non-cluster, mais satisfont au moins la partie retour de la requête. Si je laisse la clé primaire telle quelle, et indexe indépendamment ClientID et RegionID, cela me donne 3 index qui doivent être maintenus par le SGBDR, PLUS un scan de table serait toujours nécessaire pour retourner ProfileName car il n'est pas t couvert. Cela semble lourd.

Une étude de cas simple sur la façon dont la planification d'indexation complexe peut être.

Answer 1

Pour cette requête:

SELECT ProfileID, ProfileName 
FROM Profiles 
WHERE ClientID = ? AND RegionID = ? 
ORDER BY 
     ProfileName 

vous devez créer cet index:

CREATE INDEX ix_profiles_region_client_name ON (RegionID, ClientID, ProfileName) 

Au sein d'une seule valeur de (RegionID, ClientID), les enregistrements sont triés sur ProfileName, afin que les enregistrements IREZ triés et aucun tri supplémentaire ne sera nécessaire.

Puisque ProfileID est un PRIMARY KEY CLUSTERED, il est implicitement inclus dans chaque enregistrement d'index, il n'est donc pas nécessaire de le spécifier explicitement dans la définition d'index.

S'il n'y avait pas une clé en cluster, vous devez l'ajouter à l'index pour couvrir cette requête:

CREATE INDEX ix_profiles_region_client_name__id ON (RegionID, ClientID, ProfileName) INCLUDE (ProfileID)