GUID-Schlüssel: Identität und Clusterung trennen

Ein global eindeutiger Bezeichner kann als öffentliche Kennung sinnvoll sein, ohne der beste Clusterschlüssel zu sein. Öffentliche Identität unterstützt Integration und verteilte Systeme. Clusterung beeinflusst dagegen Zeilenlokalität, Indexgröße und Einfügeverhalten innerhalb einer Tabelle. Diese Entscheidungen sollten getrennt bewertet werden.

Den tatsächlichen Aufwand verstehen

uniqueidentifier benötigt sechzehn Bytes, bigint acht. In einer geclusterten Rowstore-Tabelle dient der Clusterschlüssel außerdem als Zeilenlokator nichtgeclusterter Indizes. Ein breiter Schlüssel kann den Platzbedarf deshalb über die Basistabelle hinaus erhöhen. Das Ausmaß hängt auch von Indexdefinitionen, Kompression und Zeilenform ab.

Zufällige NEWID-Werte verteilen Inserts über den Schlüsselraum. Fehlt auf der Zielseite Platz, entstehen zusätzliche Seitenarbeit und mögliche Splits. Ein aufsteigender Schlüssel kann dagegen Konkurrenz auf der letzten Seite konzentrieren. Die eine Variante verteilt Aktivität, die andere bündelt sie. Keine ist für jede Last automatisch optimal.

Das Beispiel trennt einen schmalen internen Schlüssel von einer eindeutigen öffentlichen GUID. Verwenden Sie eine Wegwerfdatenbank. Es ist eine zu messende Entwurfsoption und keine allgemeine Migrationsanweisung.

CREATE TABLE dbo.KeyDesignDemo
( InternalId bigint IDENTITY(1,1) NOT NULL
    CONSTRAINT PK_KeyDesignDemo PRIMARY KEY CLUSTERED,
  PublicId uniqueidentifier NOT NULL DEFAULT NEWID(),
  CreatedAt datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME(),
  Payload nvarchar(200) NOT NULL,
  CONSTRAINT UQ_KeyDesignDemo_PublicId UNIQUE NONCLUSTERED(PublicId)
);
INSERT dbo.KeyDesignDemo(Payload) VALUES(N'example');
SELECT InternalId,PublicId FROM dbo.KeyDesignDemo;

Ein PublicId-Zugriff nutzt dessen eindeutigen nichtgeclusterten Index und kann für Payload einen zusätzlichen Lookup benötigen. Wird nur InternalId gebraucht, kann dieser entfallen. Zusätzliche INCLUDE-Spalten müssen ihren Platz- und Schreibaufwand durch reale Lesevorteile rechtfertigen.

Sequenzielle GUIDs lösen nur einen Teil

NEWSEQUENTIALID kann als Spaltendefault zufällige Insertaktivität reduzieren. Es ist kein überall verwendbarer Ersatz für NEWID. Sein Verhalten bei Neustart oder Rechnerwechsel ist außerdem keine fachliche Uhr. Verwenden Sie einen solchen Bezeichner nicht als Berechtigungsgeheimnis.

Sequenzielle Werte machen einen sechzehn Byte breiten Schlüssel nicht schmaler. Sie können Druck auf einen Einfügebereich verlagern. Unterscheiden Sie bei der Diagnose Seiten-Latches, Transaktionssperren und Storage-Wartezeiten. Eine gegen Fragmentierung gerichtete Änderung behebt nicht zwangsläufig Last-Page-Konkurrenz.

Fill Factor reserviert beim Aufbau Platz, hält ihn aber nicht dauerhaft frei. Ein niedriger Wert kann bestimmte Splits reduzieren und gleichzeitig Seitenzahl und Leseaufwand erhöhen. Leiten Sie die Einstellung aus Wachstumsmessungen ab, statt pauschal jeden Index mit großem Freiraum zu bauen.

Die gesamte Anwendung vergleichen

Messen Sie repräsentative parallele Inserts, PublicId-Suchen, interne Joins und Bereichsberichte. Erfassen Sie gesamte Indexgröße, Journalaufkommen, Seitenaktivität, Durchsatz und langsame Randfälle. Schnellere Inserts bei deutlich teureren häufigen Lookups verbessern die Anwendung nicht unbedingt.

Ein bestehender Clusterschlüsselwechsel ist eine strukturelle Migration. Erfassen Sie Fremdschlüssel, nichtgeclusterte Indizes, Replikationsanforderungen und Anwendungskonventionen. InternalId hinzuzufügen leitet vorhandene GUID-Beziehungen nicht automatisch um. Planen Sie ausdrücklich, welche Kindtabellen welche Kennung verwenden.

Bei verteilten Schreibern muss klar sein, wo Kennungen entstehen und wie Daten zusammengeführt werden. Eine lokale Identity ist allein nicht global eindeutig. Eine externe GUID kann den Integrationsvertrag erhalten, während der interne Schlüssel lokal bleibt.

Testen Sie Failover, Massenimporte, Löschen mit nachfolgenden Inserts und Daten größer als der Pufferpool. Halten Sie Sicherheitsprüfungen unabhängig von schwer erratbaren Kennungen aufrecht. Vergleichen Sie außerdem den zusätzlichen Indexpflegeaufwand der getrennten Schlüsselvariante. Das Ergebnis soll eine begründete Lastentscheidung sein, keine pauschale Regel gegen GUIDs oder für sequenzielle Werte.

Prüfen Sie nach der Migration außerdem die eindeutige Zuordnung öffentlicher und interner Kennungen.

Technische Referenzen: Microsoft Learn: Index design · Microsoft Learn: NEWSEQUENTIALID.