guid Primärschlüsselerstellung für die schnellste Abfrage select where guid in ( guid1, guid2 , guid3 ...)

Question

Es besteht die Anforderung, GUID(s) als Primärschlüssel zu verwenden. Liege ich richtig in der Annahme, dass

ProductID UNIQUEIDENTIFIER NOT NULL 
ROWGUIDCOL DEFAULT (NEWSEQUNTIALID()) PRIMARY KEY CLUSTERED 

ergibt den schnellsten Select für die Where-Klausel

productid in ( guid1 , guid2 ,..., guidn )

und verschlechtert nicht-geclusterte

natural_key like 'Something*'

unabhängig wählen. Tabelle, die nur von Benutzern abgefragt werden kann und von Grund auf programmatisch erstellt/neu angelegt wird.

Answer 1

Die Tatsache, dass Sie GUIDs als geclusterten Index verwenden, wird sich mit Sicherheit negativ auf Ihre Leistung auswirken. Selbst mit der NEWSEQUENTIALGUID sind die GUIDs nicht wirklich sequentiell - sie sind es nur teilweise. Ihre Zufälligkeit führt definitiv zu einer höheren Indexfragmentierung und damit zu weniger optimalen Suchzeiten.

Wenn Sie außerdem eine 16-Byte-GUID als Cluster-Schlüssel verwenden, wird sie zu jedem nicht geclusterten Index dieser Tabelle hinzugefügt. Das hört sich vielleicht nicht so schlimm an, aber wenn Sie 10 Mio. Zeilen und 10 nicht geclusterte Indizes haben, kostet Sie die Verwendung einer 16-Byte-GUID im Vergleich zu einer 4-Byte-INT 1,2 GByte Speicherplatz - und zwar nicht nur auf der Festplatte (die billig ist), sondern auch im Speicher Ihres SQL-Servers (da der SQL-Server immer ganze 8k-Seiten in 8k-Speicherblöcke lädt, egal wie voll oder leer sie sind).

Ich kann den Sinn der Verwendung einer GUID als Primärschlüssel verstehen - ihre fast 100%ige Garantie, eindeutig zu sein, ist für Entwickler attraktiv. ABER: als Clusterschlüssel sind sie ein Alptraum für Ihre Datenbank.

Meine beste Praxis: Wenn ich wirklich eine GUID als Primärschlüssel benötige, füge ich der Tabelle eine 4-Byte-INT-IDENTITY hinzu, die dann als Clusterschlüssel dient - die Ergebnisse sind auf diese Weise viel besser!

Wenn Sie einen nicht geclusterten Primärschlüssel haben, sind Ihre Abfragen mit einer Liste von GUIDs genauso schnell wie bei einem geclusterten Primärschlüssel, und wenn Sie keine GUIDs für Ihren geclusterten Schlüssel verwenden, ist Ihre Tabelle am Ende sogar noch leistungsfähiger.

Lesen Sie mehr über Cluster-Schlüssel und warum es so wichtig ist, den richtigen auszuwählen, im Blog von Kimberly Tripps - der Queen of Indexing, die die Dinge viel besser erklären kann als ich:

• GUIDs als PRIMARY KEY und/oder geclusterter Schlüssel
• Die Debatte um geclusterte Indizes geht weiter
• Immer größer werdender Clustering-Schlüssel - die Clustered Index Debate..........wieder!

Marc

Answer 2

Abgesehen davon, dass GUIDs schlecht sind (Antwort von marc_s), haben Sie auch eine IN-Klausel. Das läuft auf folgendes hinaus:

productid = guid1 OR productid = guid2 OR ... OR productid = guidn

...in der Praxis, was auch nicht optimal ist.

Im Allgemeinen, natural_key like 'Something%' ist höchstwahrscheinlich besser für einen geclusterten Index auf Ihrer nativen Schlüsselspalte geeignet.

Answer 3

Ein geclusterter Index eignet sich am besten für Bereichssuchen, so dass er Ihre Anfrage erfüllen könnte:

productid in ( guid1 , guid2 ,..., guidn )

aber es hängt davon ab, was Sie sonst noch auswählen, gruppieren nach, ordnen nach usw., wenn der Index ein abdeckender Index sein soll. Andernfalls könnte ein anderer, nicht geclusterter Index vom Optimierer ausgewählt werden, gefolgt von einem Lookup in den geclusterten Index. Es hängt auch in gewissem Maße von der Anzahl der Zeilen in dieser Tabelle ab.

Außerdem denke ich, dass Sie NEWID() anstelle von NEWSEQUENTIALID() verwenden sollten.