Différence de performances SQL Server avec une clé primaire à une ou plusieurs colonnes?

Question

Y at-il une différence de performance (en termes d'insertion/mise à jour &) d'une table si la clé primaire est une seule colonne (par exemple, un GUID généré pour chaque ligne) ou plusieurs colonnes (par exemple, une clé étrangère GUID + numéro de décalage)?

Je suppose que les vitesses d'interrogation devraient être plus rapides si quelque chose avec des clés primaires à plusieurs colonnes, mais j'imagine que l'insertion serait plus lente en raison d'une vérification unique légèrement plus compliquée? J'imagine également que les types de données d'une clé primaire multi-colonne pourraient également avoir une importance (par exemple, si l'une des colonnes était un type DateTime, cela ajouterait de la complexité). Ce sont juste mes pensées pour invoquer des réponses & discussion (heureusement!) Et ne sont pas fondées sur les faits.

Je me rends compte qu'il y a some autres questions couvrant ce sujet, mais je m'interroge sur les impacts sur les performances plutôt que sur la gestion/les préoccupations commerciales.

Answer 1

Vous serez plus affecté par (chaque) composant de la clé étant (a) de longueur variable et (b) la largeur [large au lieu de colonnes étroites], que le nombre de composants dans la clé. Sauf si MS l'a encore cassé dans la dernière version (ils ont cassé Heaps en 2005). Le type de données ne le ralentit pas; la largeur, et en particulier la longueur variable (n'importe quel type de données) fait. Notez qu'une colonne fixed len est rendue variable si elle est définie sur Nullable. Les colonnes de longueur variable dans les index sont de mauvaises nouvelles, car un peu de "décompactage" doit être effectué à chaque accès, pour obtenir les données.

Évidemment, gardez les colonnes indexées aussi étroites que possible, en utilisant uniquement des colonnes fixes et non nulles.En termes de nombre de colonnes dans une clé composée, il est certain qu'une colonne est plus rapide que sept, mais pas beaucoup: trois colonnes larges larges sont beaucoup plus lentes que sept colonnes fixes minces.

GUID est bien sûr une très grosse clé; GUID plus rien d'autre est très très gros; GUID Nullable est le matériel Guiness. Malheureusement, c'est la réaction instinctive à la résolution du problème IDENTITY, qui à son tour est une conséquence de ne pas avoir choisi de bonnes clés relationnelles naturelles. Il est donc préférable de régler le problème réel à la source et de choisir de bonnes clés naturelles; éviter l'IDENTITÉ; éviter GUID.

L'expérience et l'optimisation des performances, pas de conjecture.

Answer 2

Cela dépend de vos modèles d'accès, de votre taux de lecture/écriture et de la possibilité de définir (le plus important) l'index clusterisé sur la clé primaire.

Règle générale, réduisez votre clé primaire au minimum (32 bits int) et définissez l'index clusterisé sur une clé monotone (pensez à IDENTITY) lorsque cela est possible, sauf si vous effectuez des recherches de plages qui représentent une grande partie du requêtes sur cette table.

Si votre application est écrire intensive, et vous définissez l'index ordonné en clusters sur la colonne GUID vous devez noter:

1. Tous les index non-cluster se contiennent la clé d'index ordonné en clusters et sera donc plus grande. Cela peut avoir un effet négatif sur les performances s'il existe de nombreux index CN.

2. Sauf si vous utilisez un « commandé » GUID (comme un COMB ou en utilisant NEWSEQUENTIALID()), vos inserts fragmenteront l'indice au fil du temps. Cela signifie vous avez besoin d'un index régulier à la reconstruction et éventuellement augmenter la quantité de espace libre dans les pages (facteur de remplissage )

Parce qu'il ya beaucoup de facteurs au travail (matériel, des modèles d'accès, la taille des données) , Je suggère que vous exécutiez quelques tests et référence vos circonstances particulières.

Answer 3

Cela dépend de l'indexation et du stockage dans chaque cas. Toutes choses étant égales par ailleurs, le choix de la clé primaire n'est pas pertinent en ce qui concerne les performances. Le choix des index et d'autres options de stockage serait le facteur décisif.

Answer 4

Si votre situation est orientée vers un plus grand nombre d'inserts, alors le plus petit encombrement possible est le meilleur.

Vous devez séparer deux éléments: le concept de la clé primaire au niveau de la base de données et le concept de la clé utilisée par votre application.

Pourquoi avez-vous besoin d'un GUID? Allez-vous insérer dans plusieurs serveur de base de données, puis en combinant les informations dans une base de données centralisée?

Si tel est le cas, ma recommandation est une identité suivie d'un guid. Index clusterisé sur l'identité et Unique Non clusterisé sur le GUID. Si vous utilisez le GUID en tant qu'index en cluster, vos insertions de données seront partout. Cela signifie que vos données ne seront pas insérées de manière séquentielle, ce qui entraîne des problèmes de performances, car votre système insérera et déplacera les pages de manière aléatoire.

Avoir vos données insérées bien dans une faction ordonnée, grâce à l'identité, est la voie à suivre. Vous pouvez laisser le tri à la structure d'index (l'unique nonclusered contenant le GUID), qui est une structure beaucoup plus efficace pour trier que l'utilisation des données de table.