Différence entre index clusterisé et non clusterisé

Question

Ok, je suis dans le milieu de l'élaboration d'un projet sur mon propre (première fois pour moi pour cette échelle) et il a commencé, dans la précipitation, donc mes tables sont un peu misérable. J'ai besoin d'ajouter des index correct " et ont besoin d'aide.

Je suis confus, besoin d'éclaircir quelques points:

• Dois-je utiliser les index pour les non-int colonnes? Pourquoi/pourquoi pas
• J'ai beaucoup lu sur le cluster et les index non-cluster et pourtant je n'arrive toujours pas à décider quand utiliser une. Un bon exemple pourrait m'aider et beaucoup d'autres développeurs.

Je sais que je ne devrais pas utiliser les index pour les colonnes ou les tables qui sont souvent mis à jour. C'est dans la poche pour le moment. Que dois-je faire attention et comment puis-je savoir que c'est tout bon avant de passer à la phase de test?

Merci,

Answer 1

Un index cluster modifie la façon dont les lignes sont stockées. Lorsque vous créez un index cluster sur une colonne (ou un nombre de colonnes), SQL server trie les lignes du tableau par colonne(s). C'est comme un dictionnaire où tous les mots sont classés par ordre alphabétique dans l'ensemble du livre.

Un index non-cluster, d'autre part, ne modifie pas la façon dont les lignes sont stockées dans la table. Il crée un de complètement différent de l'objet dans la table qui contient la colonne(s) sélectionné pour l'indexation et un pointeur de retour pour les lignes du tableau contenant les données. C'est comme un index dans les dernières pages d'un livre, où les mots clés sont triés et contenir le numéro de la page à la matière du livre pour les plus rapides de référence.

voici un très bon détail (source): http://www.itbully.com/node/66

Answer 2

Vous avez vraiment besoin de garder deux questions en dehors:

1) la clé primaire est une logique de la construction de l'un des candidats les touches de manière unique et fiable identifie chaque ligne dans la table. Cela peut être n'importe quoi, vraiment - un INT, un GUID, une chaîne de ramasser ce qui fait le plus de sens pour votre scénario.

2) la clé de cluster (la ou les colonnes qui définissent la "index cluster" sur la table) - c'est un physique de stockage liées à la chose, et ici, un petit, stable, de plus en plus de type de données est votre meilleur choix - INT ou BIGINT votre option par défaut.

Par défaut, la clé primaire dans une table SQL Server est également utilisé en tant que clé de cluster - mais qui n'a pas besoin d'être de cette façon!

Une règle de base que j'applique est la suivante: toute "normal" (celui que vous utilisez pour stocker des données, qui est une table de correspondance, etc.) doit avoir une clé de clustering. Il n'y a vraiment aucun point de ne pas avoir une clé de clustering. En fait, contrairement à une idée, avoir une clé de clustering en fait les vitesses de toutes les opérations courantes - même les insertions et les suppressions (depuis le tableau de l'organisation est différente et généralement mieux avec un tas - une table sans clé de cluster).

Kimberly Tripp, la Reine de l'Indexation a un grand nombre d'excellents articles sur le sujet de pourquoi avoir une clé de cluster, et quels types de colonnes pour mieux utiliser votre clé de cluster. Puisque vous obtenez seulement un par table, il est de la plus haute importance à choisir la droite clé de cluster - et pas seulement la clé de cluster.

• Guid comme CLÉ PRIMAIRE et/ou clé cluster
• L'index cluster continue de faire débat
• Toujours croissant de clustering - clés de l'Index Cluster Débat..........nouveau!
• L'espace disque est bon marché - c'est pas au point!

Marc

Answer 3

Vous devriez être en utilisant des indices pour aider les performances de SQL server. Habituellement, cela implique que les colonnes qui sont utilisés pour trouver les lignes de la table sont indexés.

Les index en cluster rend SQL server ordre les lignes sur le disque en fonction de l'ordre d'index. Cela implique que si vous accédez à des données dans l'ordre d'un index cluster, puis les données seront présents sur le disque dans l'ordre correct. Toutefois, si la colonne(s) qui ont un index cluster est souvent changé, la ligne(s) va se déplacer sur le disque, provoquant des frais généraux - qui n'est généralement pas une bonne idée.

Ayant de nombreux index n'est pas bon non plus. Ils coûtent à maintenir. Donc, commencer avec les plus évidents, et puis profil pour voir ceux qui vous manque et qui serait à l'avantage de. Vous n'avez pas besoin de démarrer, ils peuvent être ajoutés plus tard.

La colonne la plus à des types de données peut être utilisé lors de l'indexation, mais il est préférable d'avoir de petites colonnes indexées que les grandes. Aussi, il est courant de créer des index sur des groupes de colonnes (par exemple, pays + ville + de la rue).

Aussi, vous ne verrez pas de problèmes de performances jusqu'à ce que vous avez un peu de données dans vos tables. Et une autre chose à penser, c'est que le serveur SQL doit statistiques pour faire sa requête optimisations de la bonne façon, alors assurez-vous que vous ne générer que.

Answer 4

Une comparaison d'un index non-cluster avec un index en cluster avec un exemple

Comme exemple d'un index non-cluster, disons que nous avons un index non ordonné en clusters sur la colonne EmployeeID. Un index non-cluster va stocker à la fois la valeur de la

EmployeeID

ET un pointeur vers la ligne dans la table des Employés où cette valeur est stockée. Mais un index cluster, d'autre part, l'effet de stocker les données de ligne pour un particulier Employé – donc, si vous exécutez une requête qui recherche un Employé de 15, les données à partir d'autres colonnes de la table comme

EmployeeName, EmployeeAddress, etc

. allons tous être stockés dans le nœud feuille de l'index cluster lui-même.

Cela signifie que, avec un index non-cluster travail supplémentaire est nécessaire pour suivre le pointeur de la ligne dans la table de récupérer toutes les autres valeurs, par opposition à un index cluster qui peut simplement accéder à la ligne, directement depuis qu'il est en train d'être stockés dans le même ordre que celui de l'index cluster lui-même. Donc, la lecture à partir d'un index cluster est généralement plus rapide que la lecture à partir d'un index non ordonné en clusters.

Answer 5

En général, l'utilisation d'un index sur une colonne qui va être utilisé (beaucoup) à la recherche de la table, comme une clé primaire (qui a par défaut un index cluster). Par exemple, si vous avez la requête (en pseudo-code)

SELECT * FROM FOO WHERE FOO.BAR = 2

Vous pourriez mettre un index sur le FOO.BAR. Un index cluster doit être utilisé sur une colonne qui sera utilisée pour le tri. Un index cluster est utilisé pour trier les lignes sur le disque, vous ne pouvez avoir qu'un par table. Par exemple, si vous avez la requête

SELECT * FROM FOO ORDER BY FOO.BAR ASCENDING

Vous pourriez envisager un index cluster sur le FOO.BAR.

Probablement la considération la plus importante est de savoir combien de temps vos requêtes. Si une requête ne prendra pas beaucoup de temps ou n'est pas utilisé très souvent, il peut ne pas être intéressant d'ajouter des index. Comme toujours, le profil d'abord, puis de les optimiser. SQL Server Studio peut vous donner des suggestions sur l'endroit où l'optimiser, et MSDN a quelques informations1 que vous pourriez trouver utiles