J'ai cherché un peu et je n'ai vu aucune 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 faut-il utiliser un indice en cluster?
Un index peut-il jamais ralentir les performances des déclarations ? Combien d'index est trop élevé et de quelle taille d'une table avez-vous besoin pour pouvoir bénéficier d'un index?
EDIT:
Qu'en est-il des types de données de colonne? Est-il correct d'avoir un index sur un varchar ou datetime ?
6 Réponses :
C'est vraiment une question très impliquée, bien qu'un bon point de départ serait d'indexer toute colonne que vous filtrerez des résultats. c'est à dire. Si vous cassez souvent des produits en groupes par prix de vente, indexez la colonne Sale_Price de la table des produits pour améliorer les temps de numérisation pour cette requête, etc.
Si vous interrogez sur la base de la valeur dans une colonne, vous souhaitez probablement indexer cette colonne.
IE P>
SELECT a,b,c FROM MyTable WHERE x = 1
Vous devez utiliser un index sur les colonnes que vous utilisez pour la sélection et la commande - c'est-à-dire l'endroit où et l'ordre par clauses.
index peut ralentissement comme pour la taille de la table - plusieurs milliers de lignes et vers le haut commencent à montrer de véritables avantages à l'utilisation de l'index.
Cela dit, il existe des outils automatisés pour le faire, et SQL Server a un Conseiller de syntonisation de la base de données qui aidera avec cela. Sélectionnez les instructions S'il y en a beaucoup d'entre elles et que vous utilisez où et commandez sur des colonnes qui n'ont pas été indexées.
L'ITW est désormais appelé "Conseiller Tuning de la base de données (DTA)" dans SQL Server 2005 et UP
Eh bien, la première question est facile:
Quand faut-il utiliser un indice en cluster?
TOUJOURS. Période. Sauf pour un très rare, rares, des cas de bord. Un index en cluster fait une table plus rapidement, pour chaque opération. OUI! Cela fait. Voir l'excellent Le débat sur l'index en cluster continue Pour les informations de fond. Elle mentionne également ses principaux critères pour un index en cluster:
- étroit
- statique (jamais changements)
- unique
- Si jamais possible: toujours croissant
L'identité int remplit cela parfaitement - le GUID n'est pas. Voir GUID comme principal Clé pour des informations de fond étendues.
pourquoi étroit? Parce que la clé de clustering est ajoutée à chaque page d'index de chaque index non clustered sur le même tableau (afin de pouvoir réellement rechercher la ligne de données , si besoin). Vous ne voulez pas que 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 trouver de manière unique une ligne de données. Il doit être unique. Si vous choisissez une clé de clustering non unique, SQL Server lui-même ajoutera un joueur 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 faisant référence à une autre table doit être indexée, elle accélérera les jointures et autres opérations.
En outre, toutes les requêtes qui ont l'endroit où les clauses sont un bon candidat - choisissez celles qui sont beaucoup exécutées. Mettre des indices sur des colonnes qui apparaissent dans les clauses, dans l'ordre des déclarations.
Suivant: Mesurez votre système, vérifiez les informations sur les indices inutilisés ou manquants, puis modifiez encore et encore une fois votre système. C'est un processus continu, vous ne serez jamais fait! Voir ici pour info sur ces deux DMV (indices manquants et inutilisés).
Un autre mot d'avertissement: avec une charge de camion d'index, vous pouvez rendre une requête sélectionnée aller vraiment très vite. Mais en même temps, les insertions, les mises à jour et les suppressions qui doivent mettre à jour tous les indices impliqués pourraient souffrir. Si vous ne sélectionnez jamais seulement - allez sur Nuts! Sinon, c'est un acte d'équilibrage fin et délicat. Vous pouvez toujours modifier une seule requête au-delà de la croyance - mais le reste de votre système pourrait souffrir. Ne Over-Index Votre base de données! Mettez quelques bons indices en place, vérifiez et observez comment le système se comporte, puis ajoutez peut-être un autre ou deux, et encore: observer comment la performance totale du système est affectée par cela.
+1 Pour noter que c'est un processus continu et non quelque chose que vous venez de faire une fois.
En fait, notre dB est à la fois SQL Server et Postgres .. Vous avez donc un peu trop spécifique sur la mise en œuvre, mais sinon une bonne explication.
Oui, compte tenu Oracle n'a pas d'index de clustering en tant que tels (ils ont des tables organisées index et des clusters B-Tree) et un indice de clustering sur DB2 pour Z / OS est utilisé comme ligne directrice pour les données de grappes, mais pas la loi. Les index peuvent augmenter les sélections de ralentissement, si l'optimiseur n'a pas de bonne manipulation sur la cardinalité du jeu de résultats - une analyse complète peut être moins chère qu'un accès index.
La règle de base est la clé primaire (implicite et par défaut à clustered) et chaque colonne de clé étrangère
Il y a plus que vous puissiez faire pire que d'utiliser SQL Server's Index DMVS
Un index peut ralentir une sélection si l'optimiseur fait un mauvais choix et qu'il est possible d'en avoir trop. Trop nombreux seront ralentis, mais il est également possible de chevaucher des index
Répondre à ceux que je peux dire que chaque table, quelle que soit sa petite taille, bénéficiera toujours d'au moins un indice car il doit y avoir au moins une solution dans laquelle vous souhaitez rechercher les données; Sinon, pourquoi le stocker?
Une règle générale pour l'ajout d'index serait si vous devez trouver des données dans la table à l'aide d'un champ particulier ou d'un ensemble de champs. Cela entraîne le nombre d'index trop nombreux, généralement plus vous aurez les inserts et les mises à jour plus lents, car ils doivent également modifier les index, mais tout dépend de la manière dont vous utilisez vos données. Si vous avez besoin d'insertions rapides, n'en utilisez pas trop. Dans la signification des stocks de données de type "en lecture seule", vous pouvez en avoir plusieurs pour faire toutes vos recherches plus rapidement.
Malheureusement, il n'y a personne de règle pour vous guider sur le numéro ou le type d'index à utiliser, bien que l'optimiseur de requête de votre DB choisi puisse donner des indications sur la base des requêtes que vous exécutez.
En ce qui concerne les index groupés, ils sont la carte ACE que vous ne pouvez utiliser qu'une seule fois, alors choisissez soigneusement. Il vaut la peine de calculer la sélectivité du champ que vous envisagez de la mettre en jeu, car il peut être gaspillé pour le mettre sur quelque chose comme un champ booléen (exemple de valeur) car la sélectivité des données est très faible.
@Tony "Sinon pourquoi le stocker" Qu'en est-il d'un journal système où le journal est inséré dans très souvent (plusieurs fois par minute), mais les données ne sont récupérées que lorsque quelque chose se passe lorsque le journal est nécessaire (comme dans, comme chaque mois ou deux)
@Earlz: point équitable, mais lorsque vous consultez le journal, un index vous aidera à rechercher les millions de lignes que la table du journal contient. Je peux voir que j'étais un peu sur le dessus avec cette déclaration :)
"Est-il correct d'avoir un index sur un Varcharne ou DateTime?" J'ai une table dans laquelle l'index en cluster est sur une date d'heure (bien que nous n'utilisons que la partie de date) car toutes les requêtes de la table sont limitées à une paire de date de début / de fin et la sélectivité des données est suffisamment élevée pour le faire un bon choix.