Vue d'index: Comment choisir l'index cluster?

Question

Je vais faire une vue indexée, basée sur trois tables avec intérieur et extérieur des jointures entre eux (SQL Server 2005). Je vais courir toutes sortes de requêtes sur ce point de vue. Alors, je me demande quelle est la meilleure façon de choisir l'index à se regrouper. Quels sont les critères ou est-il des outils pour me aider autour.

(Désolé si ma question est terne, je n'ai pas beaucoup d'expérience dans les bases de données conception).

Merci d'avance!

EDIT:. Je fais des précisions ici, que les tableaux que j'utilise dans la vue sont l'utilisation très intense et tout frais généraux que je prends pour l'entretien des indices, devrait être payé-off

Answer 1

Comme il est un index, vous devez choisir une colonne (ou un ensemble de colonnes) qui est garanti dans tous les cas non nul et unique. Ce sont les plus grands et les plus strictes critères -. Tout ce qui peut NULL ou en double est hors de question dès le départ-go

En fonction du type de requêtes que vous courrez sur ce point de vue indexée, vous pouvez également voir si vous avez des colonnes (par exemple une date ou quelque chose) que vous allez exécuter des requêtes de portée contre. Cela pourrait faire un candidat intéressant pour une clé de cluster.

Mais la chose principale est: votre clé de cluster doit être unique et non nulle en toute circonstance. Et dans mon expérience personnelle, pour réduire la taille de l'index (et donc d'augmenter le nombre d'entrées par page), je vais essayer d'utiliser la plus petite clé possible - une seule INT est le meilleur, ou une combinaison de deux interceptions - ou peut-être un GUID -! mais ne pas utiliser des champs VARCHAR (500) dans votre clé de cluster

UPDATE : à tous ceux qui l'affiche nous disent les index clusterisés ne doivent pas nécessairement être unique - vérifier ce que la « reine d'indexation », Kimberly Tripp, a à dire sur le sujet:

  

Commençons par les choses principales que je   rechercher dans une clé de cluster:

* Unique
* Narrow
* Static

     

Pourquoi unique?   Une clé de cluster doit être   unique, car une clé de cluster (lorsque   il existe) est utilisé comme clé de recherche   de tous les index non-cluster. Prendre   par exemple un indice dans le dos d'un   livre - si vous avez besoin de trouver les données   que un des points d'entrée d'index à - que   entrée (l'entrée d'index) doit être unique   sinon, quelle entrée d'index serait   celui que vous cherchez? Donc quand   vous créez l'index cluster - il   doit être unique. Mais, SQL Server   ne nécessite pas que votre cluster   clé est créée sur une colonne unique. Toi   peut créer sur une colonne (s) que vous feriez   comme. En interne, si le regroupement   clé n'est pas unique, alors SQL Server   « Uniquify » en ajoutant un octet 4   entier aux données. Donc, si le   index ordonné en clusters est créé sur   quelque chose qui est pas unique alors pas   seulement il y a une charge supplémentaire à   création d'index, il y a gaspillée disque   l'espace, des coûts supplémentaires et sur INSERTs   UPDATEs et dans SQL Server 2000,   il y a un coût supplémentaire sur une CLUSTERED   reconstruction d'index (qui, en raison de la   mauvais choix pour la clé de cluster est   maintenant plus probable).

Source:

Answer 2

La règle de base: Sélectionnez les colonnes qui vous allez probablement utiliser la plupart dans vos requêtes comme WHERE, GROUP etc. Ces colonnes pourrait être un bon candidat pour les index non-cluster. Sélectionnez une colonne (ou un groupe de colonne) qui serait probablement rendre votre ligne unique, et qui pourrait être un bon candidat pour l'index cluster.

Comme mentionné par marc, un index ordonné en clusters impose une contrainte unique, donc il vraiment nécessaire que la colonne SELCT ne devriez pas avoir nulle et dupliquer.

Un index ordonné en clusters ne doit pas être unique. Les colonnes il peut même être annulable. Par exemple, cela fonctionnera sans erreur:

create table  #test (col1 int identity, col2 int)
create clustered index ix_test on #test (col2)
insert into #test (col2) values (1)
insert into #test (col2) values (1) -- Duplicate in clustered index
insert into #test (col2) values (null)

Un index cluster fait partie de la structure de la table sur le disque. En tant que tel, un index cluster utilise pas d'espace disque supplémentaire.

Par défaut, les clusters SQL Server sur la clé primaire, ce qui est généralement un bon choix. Vous pouvez changer que si vous avez des questions intensives avec beaucoup de tables de référence. Modification dont l'indice est en cluster peut éliminer tables de référence.

Answer 3

La règle de base: Sélectionnez les colonnes qui vous allez probablement utiliser la plupart dans vos requêtes comme WHERE, GROUP etc. Ces colonnes pourrait être un bon candidat pour les index non-cluster. Sélectionnez une colonne (ou un groupe de colonne) qui serait probablement rendre votre ligne unique, et qui pourrait être un bon candidat pour l'index cluster.

Comme mentionné par marc, un index ordonné en clusters impose une contrainte unique, donc il vraiment nécessaire que la colonne SELCT ne devriez pas avoir nulle et dupliquer.

Answer 4

Un index ordonné en clusters ne doit pas être unique. Les colonnes il peut même être annulable. Par exemple, cela fonctionnera sans erreur:

create table  #test (col1 int identity, col2 int)
create clustered index ix_test on #test (col2)
insert into #test (col2) values (1)
insert into #test (col2) values (1) -- Duplicate in clustered index
insert into #test (col2) values (null)

Un index cluster fait partie de la structure de la table sur le disque. En tant que tel, un index cluster utilise pas d'espace disque supplémentaire.

Par défaut, les clusters SQL Server sur la clé primaire, ce qui est généralement un bon choix. Vous pouvez changer que si vous avez des questions intensives avec beaucoup de tables de référence. Modification dont l'indice est en cluster peut éliminer tables de référence.