guid Primärschlüsselerstellung für die schnellste Abfrage auswählen wo guid in (guid1, guid2, guid3 ...)

Question

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

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

die schnellste wählen für where-Klausel

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

geben und sich nicht verschlechtert nicht gruppierten

natural_key like 'Something*'

unabhängig wählen. Tabelle für die Abfrage nur von Benutzern und erstellt/neu erstellt von Grund auf neu.

Answer 1

Ein Clustered-Index ist am besten geeignet, sucht zu reichen, so dass es Ihre Anfrage erfüllen könnten:

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

hängt aber was sonst Sie auswählen, die Gruppierung durch, Bestellung von etc, wenn der Index eine Abdeckung sein Index. Andernfalls wird möglicherweise ein anderer nicht gruppierter Index vom Optimierer ausgewählt, gefolgt von einer Suche im Clustered-Index. Es hängt auch in gewissem Maße von der Anzahl der Zeilen in dieser Tabelle ab.

Auch ich glaube, Sie könnten NEWID verwenden möchten() in Bezug auf NEWSEQUENTIALID entgegensetzen()

Answer 2

Die Tatsache, Sie GUID als Clustered-Index verwenden werden definitiv negativ auf Ihre Leistung auswirken. Sogar mit dem NEWSEQUENTIALGUID sind die GUIDs nicht wirklich sequentiell - sie sind nur teilweise. Ihre Zufälligkeit von Natur aus wird definitiv zu einer höheren Indexfragmentierung und somit zu weniger optimalen Suchzeiten führen.

Wenn Sie eine 16-Byte-GUID als Clusterschlüssel haben, wird sie außerdem einem beliebigen nicht gruppierten Index für diese Tabelle hinzugefügt. Das hört sich vielleicht nicht so schlimm an, aber wenn du 10 Millionen hast. Zeilen, 10 nicht gruppierte Indizes, die eine 16-Byte-GUID vs. 4-Byte-INT verwenden kostet Sie 1,2 GByte Speicherplatz verschwendet - und nicht nur auf Festplatte (was billig ist), sondern auch in Ihrem SQL-Server-Speicher (seit SQL Server lädt immer ganze 8k Seiten in 8k Blöcke Speicher, egal wie voll oder leer sie sind.

Ich kann den Punkt der Verwendung einer GUID als Primärschlüssel sehen - sie sind fast 100% Garantie, einzigartig zu sein ist ansprechend für Entwickler. ABER: Als Clusterschlüssel sind sie ein Albtraum 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 viel besser!

Wenn Sie einen nicht gruppierten Primärschlüssel haben, sind Ihre Abfragen mit der Liste der GUIDs genauso schnell wie mit einem gruppierten Primärschlüssel. Wenn Sie keine GUIDs für Ihren Clusterschlüssel verwenden, wird Ihre Tabelle noch besser schlussendlich.

Lesen Sie mehr auf Clustertaste nach oben und warum es so wichtig, die richtigen in Kimberly Tripps' Blog zu holen - die die Königin von Indexing und kann die Dinge viel besser erklären als ich:

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!

Marc

Answer 3

Ebenso wie GUIDs schlecht sind (Antwort von marc_s), haben Sie auch eine IN-Klausel. Diese Schnäbel sind:

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

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

Im Allgemeinen ist natural_key like 'Something%' wahrscheinlich am besten für einen gruppierten Index auf Ihrer natürlichen Schlüsselspalte.