Combien de champs à inclure dans un index SQL

Question

je le tableau suivant avec des millions de lignes

+----+----------+-----------+--------+-------+-------------+------------------+ 
| ID | ClientID | ProjectID | Status | Note | AccountOwner| + 7 more fields | 
+----+----------+-----------+--------+-------+-------------+------------------+ 

avec des indices sur ID (clusted) et ClientID (non groupés)

Je suis en train pour réduire le temps d'exécution en utilisant des colonnes INCLUDE sur l'index ClientID. J'ai plusieurs requêtes pour ce tableau, mais deux plus courantes sont:

SELECT ID, ClientID, ProjectID, Status WHERE ClientID = 4987 

et

SELECT ID, ClientID, AccountOwner, + 5 more fields WHERE ClientID = 4987 

Pour utiliser la INCLUDE fonction pour couvrir les deux requêtes, je devrais inclure 8 ou 9 champs sur l'index ClientID. Lors des tests, le temps de requête est réduit de 20 secondes à 2, de sorte que la fonctionnalité semble être ce dont j'ai besoin. Le problème que j'ai est qu'il semble que ce soit trop de champs mais semble nécessaire pour couvrir les deux cas d'utilisation courants et je ne sais pas assez comment cela fonctionne en interne pour savoir si c'est une bonne idée ou non. Est-ce trop de champs? Y at-il une autre caractéristique à utiliser ou un moyen de tester et de voir l'impact d'avoir autant de champs sur le INCLUDE?

Edit: Je ne demande pas de créer un index sur deux champs, je demande sur l'utilisation de la fonction d'un index (http://msdn.microsoft.com/en-us/library/ms190806.aspx)

Answer 1

L'indice « Inclure les colonnes » sera plus grand, en prenant un peu plus longue à chercher (car moins de l'index peut être stocké sur 1 page), prendre plus d'espace de stockage, prendre plus de mémoire lors de la recherche, besoin de plus de mise à jour lorsque quelqu'un met à jour un enregistrement.

Si vous avez 2 recherches très courantes, l'alternative est d'avoir 2 index 1 pour chaque cas d'utilisation. Cela prendra probablement plus d'espace de stockage, mais réduira le temps de recherche (peut-être incommensurablement en fonction de la taille de la table). Chaque index prendrait moins d'espace sur le disque et en mémoire, mais combiné prendrait probablement plus de place. L'insertion d'un enregistrement ou la mise à jour de la colonne ClientID dans la table prendrait plus de temps car les deux index devraient éventuellement être mis à jour. Personnellement, j'irais avec l'index 1 qui couvre les deux requêtes.

Answer 2

Dans votre cas, les deux requêtes utilisent la même colonne ClientID dans la clause where. Un index INLCUDE seul ClientId devrait suffire pour les deux. L'index basé sur les colonnes de la clause where ne sélectionne pas caluse.

Answer 3

Je comprends qu'il parle de la fonctionnalité Inclure de l'index, et cette fonctionnalité est pour les champs dans la sélection. Je comprends votre situation. J'ai fait face au même problème dans le passé. Vous devez faire votre propre test pour voir quel scénario correspond le mieux à vos besoins. Vous pouvez créer un index par ClientID incluant le reste des champs et rendra votre requête beaucoup plus rapide. Mais l'index sera énorme et prendra beaucoup d'espace disque. Dans ce cas, je suggère fortement de diviser votre index et les données sur différents groupes de fichiers si possible disque fisical différent. Je suis mon scénario en utilisant include sur index rendre ma requête beaucoup plus rapide mais en revanche, 70% de l'espace utilisé par la base de données dans les index. Est ton choix.