«Éviter de créer un index cluster basé sur une clé d'incrémentation» est-il un mythe de SQL Server 2000 jours?

22

Nos bases de données sont constituées de nombreuses tables, la plupart utilisant une clé de substitution entière comme clé primaire. Environ la moitié de ces clés primaires se trouvent sur des colonnes d'identité.

Le développement de la base de données a commencé à l'époque de SQL Server 6.0.

L'une des règles suivies depuis le début était, Evitez de créer un index cluster basé sur une clé d'incrémentation , comme vous le trouverez dans ces conseils d'optimisation d'index .

Maintenant que j'utilise SQL Server 2005 et SQL Server 2008, j'ai la forte impression que les circonstances ont changé. Pendant ce temps, ces colonnes de clé primaire sont de parfaits premiers candidats pour l'index cluster de la table.

sql-server sql-server-2005 clustered-index bernd_k
la source

Réponses:

34

Le mythe remonte à avant SQL Server 6.5, qui ajoutait un verrouillage au niveau des lignes . Et fait allusion ici par Kalen Delaney .

Cela concernait les «points chauds» de l'utilisation des pages de données et le fait qu'une page entière de 2k (SQL Server 7 et supérieur utilise des pages de 8k) était verrouillée, plutôt qu'une ligne insérée Edit, fév 2012

Trouvé article faisant autorité de Kimberly L. Tripp

"Le débat sur l'index cluster continue ..."

Les hotspots étaient quelque chose que nous avons grandement essayé d'éviter AVANT SQL Server 7.0 à cause du verrouillage au niveau de la page (et c'est là que le terme hot spot est devenu un terme négatif). En fait, ce n'est pas nécessairement un terme négatif. Cependant, étant donné que le moteur de stockage a été redéfini / repensé (dans SQL Server 7.0) et inclut désormais un véritable verrouillage au niveau des lignes, cette motivation (pour éviter les zones sensibles) n'est plus là.

Edit, mai 2013

Le lien dans la réponse de lucky7_2000 semble indiquer que les hotspots peuvent exister et causer des problèmes. Cependant, l'article utilise un index cluster non unique sur TranTime. Cela nécessite l'ajout d'un unificateur. Ce qui signifie que l'indice n'est pas strictement monotone croissant (et trop large). Le lien dans cette réponse ne contredit pas cette réponse ou mes liens

Sur un plan personnel, je me suis réveillé sur des bases de données où j'ai inséré des dizaines de milliers de lignes par seconde dans une table qui a une grande colonne IDENTITY comme PK en cluster.

gbn
la source
23

Pour résumer, dans les versions modernes de SQL Server, une clé en cluster sur une colonne d'identité est l'option préférée de nos jours.

mrdenny
la source
Bref, simple, au point donc cela donne mon +1. N'oubliez pas de consulter le lien vers SQLSkills car il y a une foule de bonnes informations là-bas.
AndrewSQL
12
Cela ressemble à une commande. Aucune explication ou logique quant à la raison pour laquelle nous devrions ...
gbn
Non seulement cela ressemble à une commande, mais c'est également faux. Toute base de données nécessitant un nombre très élevé d'insertions / s rencontrera des problèmes de point d'accès si vous utilisez des clés séquentielles.
Thomas Kejser
1
J'ai dit préféré, pas obligatoire. Pour les applications normales qui constituent 98% des bases de données dans le monde, une clé en cluster sur une colonne d'identité fonctionne très bien.
mrdenny
4

vérifier ce post:

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can-cause-latch-contention.aspx

la création d'un index cluster basé sur une clé d'incrémentation peut créer des points chauds néfastes pour les performances ...

lucky7_2000
la source
1
+1 pour avoir donné ce lien. Il y a là quelques indices intéressants. Mais je pense que le résultat serait beaucoup plus convaincant s'il avait comparé le scénario donné avec un scénario avec un index non clusterisé cidx_trantime sur tblTransactions (TranTime) ou une autre alternative. N'oubliez pas que lorsque vous générez autant de données, il doit y avoir des moyens efficaces de récupérer les données, vous ne pouvez pas simplement tout jeter dans un tas.
bernd_k
@bernd_k: c'est un mauvais exemple de lien. Le tableau de l' enfant a une mauvaise clé cluster non unique qui nécessite une uniquifier interne
GBN
1
Essayez alors cette expérience: kejser.org/boosting-insert-speed-by-generating-scalable-keys
Thomas Kejser