Ist "Vermeiden Sie es, einen Clustered-Index auf der Grundlage eines inkrementellen Schlüssels zu erstellen" ein Mythos aus SQL Server 2000-Tagen?

Unsere Datenbanken bestehen aus vielen Tabellen, von denen die meisten einen ganzzahligen Ersatzschlüssel als Primärschlüssel verwenden. Etwa die Hälfte dieser Primärschlüssel befindet sich in Identitätsspalten.

Die Datenbankentwicklung begann in den Tagen von SQL Server 6.0.

Eine der Regeln, die von Anfang an befolgt wurden, war: Vermeiden Sie es, einen Clustered-Index auf der Grundlage eines inkrementellen Schlüssels zu erstellen , wie Sie in diesen Tipps zur Indexoptimierung finden .

Mit SQL Server 2005 und SQL Server 2008 habe ich den starken Eindruck, dass sich die Umstände geändert haben. In der Zwischenzeit sind diese Primärschlüsselspalten perfekte erste Kandidaten für den Clustered-Index der Tabelle.

Der Mythos geht auf die Zeit vor SQL Server 6.5 zurück, in der das Sperren auf Zeilenebene hinzugefügt wurde . Und hier von Kalen Delaney angedeutet .

Dies hing mit den "Hot Spots" der Datenseitennutzung und der Tatsache zusammen, dass eine ganze 2-KB-Seite (SQL Server 7 und höher verwenden 8-KB-Seiten) gesperrt war und nicht mit einer eingefügten Zeile. Bearbeiten, Februar 2012

Gefundener maßgeblicher Artikel von Kimberly L. Tripp

"Die Clustered-Index-Debatte geht weiter ..."

Hotspots waren etwas, das wir aufgrund von Sperren auf Seitenebene stark versucht haben, PRIOR für SQL Server 7.0 zu vermeiden (und hier wurde der Begriff Hotspot zu einem negativen Begriff). Tatsächlich muss es kein negativer Begriff sein. Da das Speichermodul (in SQL Server 7.0) überarbeitet / neu gestaltet wurde und nun eine echte Sperrung auf Zeilenebene enthält, ist diese Motivation (um Hotspots zu vermeiden) nicht mehr vorhanden.

Bearbeiten, Mai 2013

Der Link in der Antwort von lucky7_2000 scheint zu sagen, dass Hotspots existieren können und Probleme verursachen. Der Artikel verwendet jedoch einen nicht eindeutigen Clustered-Index für TranTime. Hierfür muss ein Uniquifier hinzugefügt werden. Was bedeutet, dass der Index nicht streng monoton steigt (und zu breit ist). Der Link in dieser Antwort widerspricht weder dieser Antwort noch meinen Links

Persönlich habe ich mich mit Datenbanken befasst, in denen ich Zehntausende von Zeilen pro Sekunde in eine Tabelle eingefügt habe , die eine Bigint-IDENTITY-Spalte als Cluster-PK enthält.

Zusammenfassend lässt sich sagen, dass in modernen SQL Server-Versionen ein gruppierter Schlüssel in einer Identitätsspalte heutzutage die bevorzugte Option ist.

Kimberly Tripp hat einen fantastischen Blog-Beitrag zu genau diesem Thema. Ich könnte es umschreiben, aber vertraue mir, ich würde es nicht gerecht machen. Viel Spaß beim Lesen. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increase-clustering-key-the-Clustered-Index-Debateagain!.aspx

Schauen Sie sich dort einige ihrer anderen Beiträge zum Thema Clustering-Schlüssel an. Es gibt einen guten Wissensschatz von ihrer Seite.

Überprüfen Sie diesen Beitrag:

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

Wenn Sie einen Clustered-Index auf der Grundlage eines inkrementellen Schlüssels erstellen, kann dies zu Hotspots führen, die die Leistung beeinträchtigen.