Comment savoir quand utiliser les index et quel type?

Question

J'ai cherché un peu et n'a pas vu de question similaire, alors voilà.

Comment savez-vous quand mettre un index dans une table? Comment décidez-vous quelles colonnes inclure dans l'index? Quand un index clusterisé devrait-il être utilisé?

Un index peut-il ralentir les performances des instructions select? Combien d'index est trop nombreux et quelle taille d'une table avez-vous besoin pour bénéficier d'un index?

EDIT:

Qu'en est-il des types de données de colonne? Est-il acceptable d'avoir un index sur un varchar ou un datetime?

Answer 1

Eh bien, la première question est facile:

Quand faut-il un index ordonné en clusters utiliser?

Toujours. Période. Sauf pour un très petit nombre de cas rares. Un index clusterisé rend un tableau plus rapide, pour chaque opération. OUI! Cela fait. Voir l'excellent The Clustered Index Debate continues de Kim Tripp pour des informations générales.Elle mentionne également ses principaux critères d'un index ordonné en clusters:

• étroite
• statique (ne change jamais)
• uniques
• si jamais possible: de plus en plus

INT IDENTITY répond à ce parfaitement - Les GUID ne le font pas. Voir GUID's as Primary Key pour plus d'informations.

Pourquoi réduire? Parce que la clé de cluster est ajoutée à chaque page d'index de chaque index non cluster sur la même table (afin de pouvoir rechercher réellement la ligne de données, si nécessaire). Vous ne voulez pas avoir VARCHAR (200) dans votre clé de clustering ....

Pourquoi unique? Voir ci-dessus - la clé de clustering est l'élément et le mécanisme que SQL Server utilise pour rechercher de manière unique une ligne de données. Cela doit être unique. Si vous choisissez une clé de clustering non unique, SQL Server ajoutera lui-même un caractère unique de 4 octets à vos clés. Faites attention à ça!

Suivant: indices non groupés. Fondamentalement, il y a une règle: toute clé étrangère dans une table enfant référençant une autre table doit être indexée, cela accélérera les JOINs et d'autres opérations.

De plus, toutes les requêtes qui ont des clauses WHERE sont un bon candidat - choisissez celles qui sont les premières à être exécutées. Placez les index sur les colonnes qui apparaissent dans les clauses WHERE, dans les instructions ORDER BY. Suivant: mesurez votre système, vérifiez les DMV (Dynamic Management Views) pour trouver des indices sur les index inutilisés ou manquants, et modifiez votre système encore et encore. C'est un processus continu, vous n'aurez jamais fini! Voir here for info sur ces deux DMV (indices manquants et non utilisés). Un autre avertissement: avec un chargement d'index, vous pouvez faire en sorte que n'importe quelle requête SELECT soit vraiment très rapide. Mais en même temps, INSERT, UPDATE et DELETE qui doivent mettre à jour tous les indices impliqués pourraient en souffrir. Si vous ne choisissez jamais - allez écrous! Sinon, c'est un acte d'équilibre délicat et délicat. Vous pouvez toujours modifier une seule requête au-delà de la croyance - mais le reste de votre système pourrait en souffrir. Ne pas sur-index votre base de données! Mettez quelques bons indices en place, vérifiez et observez le comportement du système, puis ajoutez-en un ou deux autres, et encore une fois: observez comment la performance globale du système est affectée par cela.

Answer 2

C'est vraiment une question très compliquée, bien qu'un bon point de départ serait d'indexer n'importe quelle colonne sur laquelle vous allez filtrer les résultats. c'est à dire. Si vous divisez souvent les produits en groupes par prix de vente, indexez la colonne sale_price de la table des produits pour améliorer les temps d'analyse pour cette requête, etc.

Answer 3

Si vous interrogez en fonction de la valeur dans une colonne, vous souhaitez probablement indexer cette colonne.

-à-dire

SELECT a,b,c FROM MyTable WHERE x = 1 

Vous voulez un index sur X.

En général, ajouter des index pour les colonnes qui sont fréquemment sollicités et ajouter les index composés quand je suis sur l'interrogation plus d'un colonne.

Les index ne nuisent pas aux performances d'un SELECT, mais ils peuvent ralentir INSERTS (ou UPDATES) si vous avez trop d'index colonnes par table. En règle générale, commencez par ajouter des index lorsque vous trouvez WHERE a = 123 (dans ce cas, un index pour "a").

Answer 4

Vous devez utiliser un index sur les colonnes que vous utilisez pour la sélection et la commande, c'est-à-dire les clauses WHERE et ORDER BY.

Index peuvent ralentir select déclarations s'il y a beaucoup d'entre eux et que vous utilisez WHERE et ORDER BY sur les colonnes qui ne sont pas indexés. En ce qui concerne la taille de la table, plusieurs milliers de lignes commenceront à montrer de réels avantages pour l'utilisation de l'index. Cela dit, il existe des outils automatisés pour ce faire, et le serveur SQL a un Database Tuning Advisor qui aidera à cela.

Answer 5

Règle de base est la clé primaire (implicite et par défaut cluster) et chaque colonne clé étrangère

Il y a plus, mais vous pourriez faire pire que d'utiliser missing index DMVs

Un index de SQL Server peut ralentir SELECT si l'optimiseur fait un mauvais choix, et il est possible d'en avoir trop. Trop d'écritures lentes, mais il est également possible de chevaucher les index

Answer 6

En répondant à celles que je peux, je dirais que chaque table, aussi petite soit-elle, bénéficiera toujours d'au moins un index, car il doit y avoir au moins un chemin dans lequel vous êtes intéressé à rechercher les données; sinon pourquoi le stocker?

Une règle générale pour ajouter des index serait si vous avez besoin de trouver des données dans la table en utilisant un champ particulier, ou un ensemble de champs.Cela conduit à combien d'index sont trop nombreux, généralement plus vous avez d'index, plus les insertions et les mises à jour sont lentes, car elles doivent aussi modifier les index, mais tout dépend de la façon dont vous utilisez vos données. Si vous avez besoin d'inserts rapides, n'en utilisez pas trop. En rapportant les magasins de données de type «lecture seule», vous pouvez en avoir plusieurs pour accélérer toutes vos recherches. Malheureusement, il n'y a pas de règle unique pour vous guider sur le nombre ou le type d'index à utiliser, bien que l'optimiseur de requêtes de votre base de données choisie puisse donner des indications basées sur les requêtes que vous exécutez. En ce qui concerne les index clusterisés, ils sont la carte Ace que vous ne pouvez utiliser qu'une seule fois. Choisissez donc avec soin. Il vaut la peine de calculer la sélectivité du champ que vous envisagez de mettre car il peut être gaspillé à le mettre sur quelque chose comme un champ booléen (exemple artificiel) car la sélectivité des données est très faible.