SQL 2005: Questions sur les clés, les index et les contraintes

Question

J'ai une série de questions sur les clés, les index et les contraintes dans SQL, SQL 2005 en particulier. Je travaille avec SQL depuis environ 4 ans, mais je n’ai jamais pu obtenir de réponses définitives sur ce sujet et il existe toujours des informations contradictoires sur les billets de blog, etc. La plupart des tables que je crée et utilise ont simplement une colonne Identity qui est une clé primaire et d’autres tables pointent vers elle via une clé étrangère.

Avec les tables de jointure, je n’ai pas d’identité et je crée une clé primaire composite sur les colonnes de clé étrangère. Vous trouverez ci-dessous un ensemble d'énoncés de mes convictions actuelles, qui peuvent être erronées. Corrigez-moi si tel est le cas, ainsi que d'autres questions.

Alors, voici:

Si je comprends bien, la différence entre un index clusterisé et un index non cluster (qu’il soit unique ou non) réside dans le fait que cet index affecte l’ordre physique des données dans une table (vous ne pouvez donc en avoir qu’un dans une table). ), alors qu’un index non-cluster construit une structure de données arborescente. Lors de la création d'index, pourquoi devrais-je me préoccuper de clusterisé ou non clusterisé? Quand devrais-je utiliser l'un ou l'autre? On m'a dit que l'insertion et la suppression sont lentes avec les index non clusterisés, car l'arborescence doit être "reconstruite". Je suppose que les index clusterisés n’affectent pas les performances de cette manière?

Je vois que les clés primaires ne sont en réalité que des index groupés uniques (doivent-ils être groupés?). Quelle est la particularité d'une clé primaire par rapport à un index unique en cluster?

J'ai aussi vu des contraintes, mais je ne les ai jamais utilisées ou vraiment regardées. On m'a dit que l'objectif des contraintes est qu'elles visent à appliquer l'intégrité des données, alors que les index visent la performance. J'ai également lu que les contraintes sont implémentées de manière concrète en tant qu'index de toute façon, de sorte qu'elles sont "identiques". Cela ne me semble pas juste. En quoi les contraintes diffèrent-elles des index?

Answer 1

Les index clusterisés sont, comme vous le dites correctement, les définition de la manière dont les données d’une table sont stockées physiquement, c’est-à-dire que vous avez un arbre B trié à l’aide de la clé de clustering et que vous avez les données au niveau feuille.

index non clusterisés sur de l’autre côté sont des structures arborescentes distinctes qui, au niveau feuille, n’ont que la clé de clustering (ou un RID si la table est un tas), ce qui signifie que lorsque vous utilisez un index non clusterisé, vous devez utiliser l’index clusterisé pour: récupérez les autres colonnes (à moins que votre demande ne soit entièrement couverte par l'index non clusterisé, ce qui peut arriver si vous ne demandez que les colonnes constituant les colonnes de clé d'index non clusterisé).

Quand devriez-vous utiliser l'un ou l'autre? Eh bien, comme vous ne pouvez avoir qu’un seul index clusterisé, définissez-le sur les colonnes, ce qui est logique, c’est-à-dire que lorsque vous recherchez des clients par ID la plupart du temps, définissez un index clusterisé sur cet ID. Les index non clusterisés doivent être définis sur des colonnes moins utilisées.

En ce qui concerne les performances, les insertions ou les mises à jour qui modifient la clé d’index sont toujours pénibles, qu’il s’agisse d’un index clusters sur un index non clusterisé, car des fractionnements de page peuvent se produire, ce qui oblige le déplacement des données (pages un index clusterisé fait plus mal, car vous avez plus de données au niveau feuille). La règle générale est donc d'éviter de modifier la clé d'index et d'insérer de nouvelles valeurs afin qu'elles soient séquentielles. Sinon, vous rencontrerez une fragmentation et devrez reconstruire votre index régulièrement.

Enfin, en ce qui concerne les contraintes, par définition, elles n’ont rien à voir avec les index, mais SQL Server a choisi de les implémenter à l’aide d’index. Par exemple. actuellement, une contrainte unique est implémentée en tant qu'index, mais cela peut changer dans une future version (bien que je doute que cela se produise). Le type d'index (en cluster ou non) dépend de vous, mais n'oubliez pas que vous ne pouvez avoir qu'un seul index en cluster.

Si vous avez d'autres questions de ce type, je vous recommande vivement de lire ce livre , qui couvre ces sujets en profondeur.

Answer 2

Votre hypothèse concernant le en cluster vs non-cluster est très bon

Il semble également que la clé primaire applique des uniquenes non nuls, tandis que l'index unique n'en impose pas non plus primaire vs unique

Answer 3

La clé primaire est un concept logique de la théorie des bases de données relationnelles. Il s'agit d'une clé (et généralement d'un index) conçue pour identifier de manière unique l'une de vos lignes. Par conséquent, il doit être unique et ne peut pas être NULL.

La clé de clustering est un concept physique de stockage de SQL Server. Il s'agit d'un index spécial qui n'est pas uniquement utilisé pour les recherches, etc., mais définit également la structure physique de vos données dans votre table. Dans un annuaire imprimé de la culture de l'Europe occidentale (sauf peut-être pour l'Islande), l'index clusterisé serait "LastName, FirstName".

Etant donné que l'index de clustering définit votre structure de données physique, vous ne pouvez en posséder qu'un seul (ou aucun - ceci n'est toutefois pas recommandé).

La configuration requise pour une clé de cluster est la suivante:

• doit être unique (sinon, SQL Server ajoutera un "uniqueificateur" sur 4 octets)
• doit être stable (ne change jamais)
• doit être aussi petit que possible (INT est préférable)
• devrait être en augmentation constante (pensez: IDENTITÉ)

SQL Server transforme votre clé primaire en clé de clustering par défaut - mais vous pouvez le modifier si vous en avez besoin. Notez également que les colonnes qui constituent la clé de clustering seront ajoutées à chaque entrée de chaque index non clusterisé de votre table. Vous souhaitez donc que votre clé de clustering soit aussi petite que possible. En effet, la clé de regroupement sera utilisée pour la " recherche de signet " - Si vous avez trouvé une entrée dans un index non groupé (par exemple, une personne par son numéro de sécurité sociale) et que vous devez maintenant récupérer toute la ligne de données pour obtenir plus de détails, vous devez effectuer une recherche, et pour cela, la clé de clustering est utilisée.

Il existe un débat intéressant sur ce qui constitue un cluster ou une clé primaire utile ou utile: voici quelques excellents articles de blog à lire à ce sujet:

• tous les articles du blog sur l'indexation de Kimberly Tripp sont incontournables
• GUID en tant que clé primaire et / ou clé de clustering
• Le débat sur l'index clusterisé continue. ..

Marc

Answer 4

Vous avez plusieurs questions. J'en briserai quelques unes:

Lors de la création d'index, pourquoi devrais-je me soucier des clusters ou non des clusters?

Parfois, vous vous souciez de la manière dont les lignes sont organisées. Cela dépend de vos données et de la manière dont vous les utiliserez. Par exemple, si votre clé primaire est un uniqueidentifier , vous ne voudrez peut-être pas qu'il s'agisse de CLUSTERED , car les valeurs du GUID sont essentiellement aléatoires. Cela entraînera SQL à insérer des lignes de manière aléatoire dans la table, entraînant des fractionnements de pages qui nuisent aux performances. Si la valeur de votre clé primaire sera toujours incrémentée de manière séquentielle ( int IDENTITY par exemple), vous voudrez probablement qu'il s'agisse de CLUSTERED , afin que votre table s'agrandisse toujours à la fin.

Une clé primaire est CLUSTERED par défaut, et la plupart du temps vous n'avez pas à vous en soucier.

On m'a dit que l'insertion et la suppression sont lentes avec les index non clusterisés car l'arborescence doit être "reconstruite". Je suppose que les index clusterisés n’affectent pas les performances de cette manière?

En fait, le contraire peut être vrai. Les index NONCLUSTERED sont conservés en tant que structure de données distincte, mais cette structure est conçue pour permettre certaines modifications sans qu'il soit nécessaire de la "reconstruire". Lors de la création initiale de l'index, vous pouvez spécifier le FILLFACTOR , qui spécifie la quantité d'espace libre à laisser sur chaque page de l'index. Cela permet à l'index de tolérer certaines modifications avant qu'un fractionnement de page ne soit nécessaire. Même si une division de page doit avoir lieu, cela n’affecte que les pages voisines, pas l’index complet.

Le même comportement s'applique aux index CLUSTERED , mais étant donné que les index CLUSTERED stockent les données de la table réelle, les opérations de fractionnement de page sur l'index peuvent être beaucoup plus coûteuses car la ligne entière vous devrez peut-être être déplacé (par opposition aux colonnes de clé et au ROWID dans un index NONCLUSTERED ).

La page MSDN suivante parle de FILLFACTOR et des fractionnements de page: http://msdn.microsoft.com/en-us /library/aa933139(SQL.80).aspx

Quelle est la particularité d'une clé primaire par rapport à un index unique en cluster? En quoi les contraintes diffèrent-elles des index?

Dans les deux cas, je pense qu'il est plus important de déclarer vos intentions. Lorsque vous appelez quelque chose une PRIMARY KEY , vous déclarez qu'il s'agit de la méthode principale pour identifier une ligne donnée. Un PRIMARY KEY est-il physiquement différent d'un INDEX UNIQUE CLUSTERED ? Je ne suis pas sûr. Le comportement est essentiellement le même, mais vos intentions peuvent ne pas être claires pour quelqu'un qui travaille avec votre base de données.

En ce qui concerne les contraintes, il existe de nombreux types de contraintes. Pour un UNIQUE CONSTRAINT , il n'y a pas vraiment de différence entre cela et un UNIQUE INDEX , à part la déclaration de votre intention. Il existe d'autres types de contraintes qui ne correspondent pas directement à un type d'index, telles que les contraintes CHECK , les contraintes DEFAULT et les contraintes FOREIGN KEY . .

Answer 5

Je n'ai pas le temps de répondre à cette question en profondeur, alors voici quelques informations que j'ai en tête:

Vous avez raison en ce qui concerne les index clusterisés. Ils réorganisent les données physiques en fonction de l'ordre de tri de l'index clusterisé. Vous pouvez utiliser les index en cluster spécifiquement pour les requêtes liées à une plage (par exemple entre des dates).

Les PK sont mises en cluster par défaut, mais elles ne doivent pas nécessairement l'être. C'est juste un paramètre par défaut. La PK est censée être un UID pour la ligne.

Les contraintes peuvent être implémentées en tant qu'index (par exemple, des contraintes uniques), mais peuvent également être implémentées en tant que valeurs par défaut.