GUIDs sind als geclusterte Schlüssel wegen der hohen Zufälligkeit problematisch. Dieses Problem wurde von Paul Randal in der letzten Q&A-Kolumne des Technet-Magazins angesprochen:Ich möchte eine GUID als Clustered-Index-Schlüssel verwenden, aber die anderen argumentieren, dass dies zu Leistungsproblemen mit Indizes führen kann. Stimmt das und wenn ja, können Sie erklären warum?
Denken Sie jetzt daran, dass sich die Diskussion speziell um Clustering dreht Indizes. Sie sagen, Sie möchten die Spalte als 'ID' verwenden, das ist unklar, ob Sie es als gruppierten Schlüssel oder nur als Primärschlüssel meinen. Normalerweise überlappen sich die beiden, also gehe ich davon aus, dass Sie es als Clustered-Index verwenden möchten. Die Gründe, warum dies eine schlechte Wahl ist, werden im Link zu dem Artikel erklärt, den ich oben erwähnt habe.
Für nicht gruppierte Indizes haben GUIDs immer noch einige Probleme, aber nicht annähernd so groß wie wenn sie der am weitesten links gruppierte Schlüssel der Tabelle sind. Auch hier führt die Zufälligkeit von GUIDs zu Seitenteilungen und Fragmentierung, sei es nur auf der Ebene des nicht geclusterten Index (ein viel kleineres Problem).
Es gibt viele urbane Legenden rund um die Verwendung von GUIDs, die sie aufgrund ihrer Größe (16 Bytes) im Vergleich zu einem Int (4 Bytes) verurteilen und einen schrecklichen Performance-Untergang versprechen, wenn sie verwendet werden. Das ist leicht übertrieben. Ein Schlüssel der Größe 16 kann bei einem richtig entworfenen Datenmodell immer noch ein sehr leistungsfähiger Schlüssel sein. Es stimmt zwar, dass eine 4-mal größere Zahl als int zu mehr Nicht-Blatt-Seiten mit geringerer Dichte führt In Indizes ist dies für die überwiegende Mehrheit der Tabellen kein wirkliches Problem. Die B-Baumstruktur ist ein natürlich gut ausbalancierter Baum und die Tiefe Das Durchlaufen von Bäumen ist selten ein Problem, daher ist die Suche nach einem Wert basierend auf einem GUID-Schlüssel im Gegensatz zu einem INT-Schlüssel in der Leistung ähnlich. Eine Blattseitentraversierung (dh ein Tabellenscan) betrachtet die Nichtblattseiten nicht, und die Auswirkung der GUID-Größe auf die Seitengröße ist typischerweise recht gering, da der Datensatz selbst erheblich größer ist als die zusätzlich eingeführten 12 Bytes durch die GUID. Also würde ich den Hören-Sagen-Rat basierend auf 'ist 16 Bytes vs. 4' mit einem ziemlich großen Salzkorn nehmen. Analysieren Sie von Fall zu Fall und entscheiden Sie, ob die Auswirkungen auf die Größe einen wirklichen Unterschied machen:wie viele andere Spalten in der Tabelle sind (d. h. wie viel Einfluss hat die GUID-Größe auf den Blattseiten) und wie viele Referenzen sie verwenden (d. h. wie viele andere Tabellen werden zunehmen, da sie einen größeren Fremdschlüssel speichern müssen).
Ich nenne all diese Details in einer Art provisorischer Verteidigung von GUIDs, weil sie in letzter Zeit viel schlechte Presse bekommen haben und einige davon unverdient sind. Sie haben ihre Vorzüge und sind in jedem verteilten System unverzichtbar (in dem Moment, in dem Sie über Datenbewegungen sprechen, sei es über Replikation oder Synchronisierungsframework oder was auch immer). Ich habe gesehen, wie schlechte Entscheidungen aufgrund des schlechten Rufs der GUID getroffen wurden, wenn sie ohne angemessene Überlegung gemieden wurden. Aber es stimmt, wenn Sie eine GUID als geclusterten Schlüssel verwenden müssen, stellen Sie sicher, dass Sie das Problem der Zufälligkeit angehen:Verwenden Sie sequentielle GUIDs wenn möglich.
Und schließlich, um Ihre Frage zu beantworten:wenn Sie keine spezifische haben Grund GUIDs zu verwenden, verwenden Sie INTs.
