reconstruire - sql server propose index




Quand créer un nouvel index SQL Server? (6)

créer un index sur une colonne BIT est inutile.

Vous seriez surpris.

J'ai dû créer un index impliquant une colonne peu pour une requête comme:

SELECT foo.Name FROM foo WHERE foo.Active = 1

Cependant, il y avait environ 300 000 lignes dans la table.

Évidemment (il me semble), créer un index sur une colonne BIT est inutile. Cependant, si vous avez une colonne que vous devez rechercher dans laquelle chaque valeur est probablement unique, comme BlogPost ou StreetAddress ou quelque chose, alors un index semble approprié (encore une fois, il me semble).

Mais quelle est la coupure? Que faire si vous attendez 10 000 lignes et vous aurez environ 20 valeurs uniques parmi eux. Un index devrait-il être créé?

Merci d'avance.


Dans la colonne que vous suggérez, il serait logique de créer une table de référence ou de recherche pour les données afin d'éviter la redondance des données. Cela ferait de votre colonne une clé étrangère, pointant vers le PK de la nouvelle table de recherche.

Toutes les colonnes de clé étrangère doivent être indexées.

Sinon, j'éviterais de placer un index dans des conditions normales sur une telle colonne.


James a frappé le clou sur la tête. Je vais juste ajouter que même une colonne peut bénéficier d'un index en fonction de la façon dont vous utilisez la table. Par exemple, si vous avez besoin de compter le nombre de lignes qui ont un nombre de fois au cours de la journée, un index peut être utile. Les index ne sont pas toujours sur la recherche d'un seul enregistrement - ils peuvent également être utilisés pour les agrégations.


Je dirais que tout dépend de l'utilisation de la table et des exigences générales du système. Par exemple, si cela fait partie d'un grand JOIN et que le parent est une énorme table de type de rapport, alors vous voudrez certainement l'index. Si elle est relativement petite par rapport à vos autres tables de la base de données, et qu'elle est fortement insérée et rarement lue, un index n'est probablement pas souhaité.

Cependant, la portée de l'opération parmi l'ensemble de la base de données par rapport aux ressources disponibles à allouer est le facteur de décision clé. C'est la façon dont cette table + index se comporte dans l'ensemble du système par rapport à toutes vos autres tables et leurs exigences. Si vous ne gardez pas la grande image à l'esprit, vous pourriez tuer tout le système en essayant d'appliquer une règle arbitraire simplement pour l'application d'une règle arbitraire.


La meilleure réponse à cela est de profiler vos requêtes et de voir si l'index améliore vos requêtes. La difficulté à répondre à ceci est qu'il est presque impossible de généraliser le comportement de l'optimiseur de requête.

Cela dit, une règle générale est que si votre sélectivité est de 10% ou moins sur une requête donnée sur une table, alors vous bénéficierez très probablement d'un index. Ainsi, dans votre exemple, vous pourriez bénéficier d'un index si vos valeurs sont réparties uniformément. Cependant, étant donné que votre table est petite, votre amélioration des performances pourrait être négligeable.

Ce n'est pas une règle absolue car de nombreux facteurs peuvent modifier le nombre de 10%, notamment l'utilisation d'un cluster ou d'autres types d'index, la taille des lignes, certaines colonnes non alignées, la structure de requête, etc.

Gardez également à l'esprit qu'il y a une pénalité de performance significative pour l'insertion dans une table avec un index. Si cette table est fréquemment mise à jour ou ajoutée, l'augmentation de la vitesse de l'index peut être annulée par les insertions et mises à jour plus lentes.

Voir l'article MSDN sur l' accès à Tablescan vs Index .

Modifier: Comme d'autres l'ont souligné, votre requête peut bénéficier d'un index si vous effectuez des requêtes d'agrégation, par exemple en comptant le nombre de fois qu'une valeur particulière apparaît. Vous pouvez également bénéficier si vous trier fréquemment sur une colonne particulière.


Les index avec une faible cardinalité sont très problématiques. S'il n'y a que plusieurs valeurs possibles, SQL Server effectue presque toujours des index-scans, quelles que soient les proportions.

Exemple: J'ai eu une table avec un champ d'état qui n'acceptait que les valeurs "A", "N", et "R" (pour actif, nouveau et retiré). Typiquement, vous aborderiez une condition où 95% étaient "R", 4 +% étaient "A", et quelques-uns étaient "N". SELECT O WH state = 'N' scanne la table, quoi qu'il arrive.

MAIS - il existe un type d'index newish appelé Filtered Index, qui gère finalement cette condition. C'est également pratique lorsque vous voulez exclure des enregistrements avec des valeurs NULL.





tsql