Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

GUID-Leistung

GUID s scheint eine natürliche Wahl für Ihren Primärschlüssel zu sein - und wenn Sie es wirklich müssen, könnten Sie wahrscheinlich argumentieren, es für den PRIMARY KEY der Tabelle zu verwenden. Was ich dringend empfehlen würde nicht zu tun Verwenden Sie die GUID Spalte als Clustering-Schlüssel , was SQL Server standardmäßig tut, es sei denn, Sie weisen ausdrücklich darauf hin.

Sie müssen wirklich zwei Dinge auseinanderhalten:

  1. der Primärschlüssel ist ein logisches Konstrukt – einer der Schlüsselkandidaten, der jede Zeile in Ihrer Tabelle eindeutig und zuverlässig identifiziert. Das kann wirklich alles sein - ein INT , eine GUID , eine Zeichenfolge - wählen Sie aus, was für Ihr Szenario am sinnvollsten ist.

  2. der Clustering-Schlüssel (die Spalte oder Spalten, die den Clustered Index definieren auf dem Tisch) - das ist eine physische speicherbezogene Sache, und hier ist ein kleiner, stabiler, ständig wachsender Datentyp Ihre beste Wahl - INT oder BIGINT als Ihre Standardoption.

Standardmäßig wird der Primärschlüssel einer SQL Server-Tabelle auch als Clusterschlüssel verwendet – aber das muss nicht so sein! Ich persönlich habe massive Leistungssteigerungen gesehen, als ich den vorherigen GUID-basierten Primär-/Clusterschlüssel in zwei separate Schlüssel aufteilte – den primären (logischen) Schlüssel auf der GUID und den Clusterschlüssel (Ordnungsschlüssel) auf einer separaten INT IDENTITY(1,1) Säule.

Als Kimberly Tripp - die Queen of Indexing - und andere haben es schon oft gesagt - eine GUID als Clustering-Schlüssel ist nicht optimal, da sie aufgrund ihrer Zufälligkeit zu einer massiven Seiten- und Indexfragmentierung und zu allgemein schlechter Performance führt.

Ja, ich weiß - es gibt newsequentialid() in SQL Server 2005 und höher - aber selbst das ist nicht wirklich und vollständig sequentiell und leidet daher auch unter den gleichen Problemen wie die GUID - nur etwas weniger prominent.

Dann gibt es noch ein weiteres Problem zu beachten:Der Clustering-Schlüssel einer Tabelle wird auch zu jedem einzelnen Eintrag in jedem nicht gruppierten Index Ihrer Tabelle hinzugefügt - daher möchten Sie wirklich sicherstellen, dass er so klein wie möglich ist. Typischerweise sollte ein INT mit mehr als 2 Milliarden Zeilen für die überwiegende Mehrheit der Tabellen ausreichen – und im Vergleich zu einer GUID als Clustering-Schlüssel können Sie sich Hunderte von Megabyte Speicherplatz auf der Festplatte und im Serverspeicher sparen.

Schnelle Berechnung - mit INT vs. GUID als Primär- und Clusterschlüssel:

  • Basistabelle mit 1.000.000 Zeilen (3,8 MB vs. 15,26 MB)
  • 6 Nonclustered-Indizes (22,89 MB gegenüber 91,55 MB)

GESAMT:25 MB gegenüber 106 MB - und das nur auf einem einzigen Tisch!

Noch ein paar Denkanstöße - ausgezeichnetes Material von Kimberly Tripp - lesen Sie es, lesen Sie es noch einmal, verdauen Sie es! Es ist wirklich das Evangelium der SQL Server-Indizierung.