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

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.

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.

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.

Kimberly Tripp a un article de blog fantastique sur ce sujet. Je pourrais paraphraser, mais croyez-moi, je ne lui rendrais pas justice. Lisez. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

Pendant que vous y êtes, consultez certains de ses autres articles sur le thème des clés de clustering. Il y a une bonne mine de connaissances sur son site.

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 ...