J'ai quelques tables avec 4 à 10 lignes. Nous ne prévoyons pas que ces tables vont grandir beaucoup plus que quelques lignes de plus.Est-il logique de mettre un index sur des tables minuscules?
Est-ce qu'il est logique de mettre un index sur leurs clés primaires.
Si elles ont des clés primaires comme vous l'avez indiqué alors vous avez déjà au moins un index. C'est probablement un index clusterisé, et je pense que vous êtes prêt à partir.
Vous devriez presque toujours avoir un index clusterisé au minimum. Je dirais oui, allez-y et indexez-les. Cela ne fera certainement pas de mal, et si les données de cette table dépassent vos attentes, vous aurez au moins une stratégie d'indexation simple en place pour aider à atténuer l'effet de l'augmentation de la taille de la table.
Si vous utilisez une clé primaire , vous avez déjà un index clusterisé.
les clés primaires ne doivent pas être groupées –
Espérons que vous avez une clé primaire qui est votre index clusterisé. Mais à part les colonnes de votre index, une table de 4 à 10 lignes est minuscule. Il y a plus de coûts associés à la recherche d'un index que d'une analyse de table réelle. Quelqu'un s'il vous plaît tenez-moi honnête ici - pour SQL 2008 dans les environnements de production et de reporting à grande échelle, nous ne dérange pas avec des indices sur les tables de moins de 50k lignes.
La bonne réponse est: IL NE COMPTE PAS.
Chaque fois que la table est suffisamment petite pour tenir dans une seule page de données de 8 Ko, le serveur SQL peut simplement charger cette page et avoir la "table entière" disponible pour faire ce dont elle a besoin.
Un cluster index est la table elle-même, donc si vous ajoutez un index cluster, vous n'êtes pas vraiment ajouter de frais généraux, vous êtes juste spécifiant une préférence de tri dans la page de données unique où réside la table . D'autre part, un index non clusterisé est un objet séparé, il ne serait donc qu'un espace perdu, car il ne serait jamais utilisé. (L'optimiseur de requête ne chargera jamais un index contenant uniquement des pointeurs vers une seule page de données, il chargera uniquement la seule page de données directement). Assurez-vous d'avoir une clé primaire, mais si vous ajoutez aussi l'index clusterisé, cela ne va pas signifier grand-chose (et ne sera probablement jamais utilisé) à moins que la table ne se développe bien au-delà d'une page .
Great info BradC. +1 :) – wcm
Je suis avec Tapori à ce sujet; l'ajout d'index ajoutera inutilement des frais supplémentaires.
Quel facteur de remplissage utiliseriez-vous pour un index clusterisé sur une table comme celle-ci? –
Le facteur de remplissage dépend vraiment de la nature des insertions et des mises à jour. Par exemple, si vous avez tendance à insérer des enregistrements dans l'ordre défini par votre index cluster et si vous effectuez peu ou pas de mises à jour, un facteur de remplissage élevé est préférable (même 100% si vous n'avez pas de mise à jour). De cette façon, vous analysez quelques pages de données autant que possible pour un chargement donné. Pour une table avec des inserts en désordre, ou plus que des mises à jour sporadiques, un facteur de remplissage inférieur est justifié. –
Et si les valeurs que vous voulez changer d'index souvent? Le regroupement ne diminuerait-il pas les performances? – johnnycrash