Gibt es einen Vorteil beim Erstellen eines Clustered-Indexes - wenn wir Datensätze basierend auf dieser Spalte nicht abfragen/suchen werden?

Question

Ich überprüfe einige DB-Tabellen, die in unserem Projekt erstellt wurden, und stolperte darüber. Die Tabelle enthält eine Identity-Spalte (ID), die der Primärschlüssel für die Tabelle ist, und ein Clustered-Index wurde mithilfe dieser ID-Spalte definiert. Aber wenn ich den SPROC ansehe, der Datensätze aus dieser Tabelle abruft, sehe ich, dass die ID-Spalte niemals in der Abfrage verwendet wird und sie die Datensätze basierend auf einer USERID-Spalte abfragen (diese Spalte ist nicht eindeutig) und es können mehrere Datensätze dafür existieren die gleiche USERID.

Also meine Frage gibt es einen Vorteil/Zweck beim Erstellen eines gruppierten Index, wenn wir wissen, dass die Datensätze nicht mit dieser Spalte abgefragt werden?

Answer 1

Ich würde sagen, Ihr Tisch ist falsch gestaltet. Jemand dachte offenbar, dass jede Tabelle einen Primärschlüssel und der Primärschlüssel der gruppierte Index benötigt. Das Hinzufügen einer systemgenerierten eindeutigen Nummer als Kennung fügt nur Rauschen hinzu, wenn diese Nummer nirgendwo verwendet wird. Rauschen im Clustered Index ist gelinde gesagt nicht hilfreich.

Sie sind übrigens unterschiedliche Konzepte. Ein Primärschlüssel ist ein Datenmodellierungsanliegen, ein logisches Konzept. Ein Index ist ein physikalisches Designproblem. Ein SQL-DBMS muss Primärschlüssel unterstützen, aber keine Indizes, Cluster oder Nein.

Wenn USERID normalerweise verwendet wird, um die Tabelle zu durchsuchen, sollte es in Ihrem gruppierten Index sein. Der gruppierte Index muss nicht eindeutig sein und muss nicht der Primärschlüssel sein. Ich würde die Daten sorgfältig untersuchen, um zu sehen, ob eine Kombination aus USERID und einer anderen Spalte (oder zwei oder mehr) eine eindeutige Kennung für die Zeile bildet. Wenn ja, würde ich den Primärschlüssel (und Clustered-Index) mit USERID als erste Spalte machen. Wenn die Abfrageanalyse gezeigt hat, dass viele Abfragen nur USERID und nichts anderes verwenden (für Existenztests), könnte ich einen separaten Index nur von USERID erstellen.

Wenn keine Kombination von Spalten eine eindeutige Kennung darstellt, haben Sie ein logisches Problem, nämlich: Was bedeutet die Zeile? Welchen Aspekt der realen Welt repräsentiert es?

Ein grundlegender Grundsatz des relationalen Modells ist, dass Elemente in einer Relation (Zeilen in einer Tabelle) eindeutig sind, dass jeder etwas identifiziert. Wenn zwei Zeilen identisch sind, identifizieren sie dasselbe. Was bedeutet es, einen von ihnen zu löschen? Ist das, was sie beide identifizieren, immer noch da oder nicht? Wenn ja, welchen Zweck hatte die 2. Reihe?

Ich hoffe, dass gibt Ihnen eine andere Möglichkeit, über gruppierte Indizes und Schlüssel nachzudenken. Ich wäre nicht überrascht, wenn Sie andere Tabellen finden, die auch verbessert werden könnten.

Answer 2

Wenn die Spalte IDENTITY niemals in WHERE und JOIN Klauseln verwendet wird oder auf Fremdschlüssel verwiesen wird, sollte USERID möglicherweise ein gruppierter Primärschlüssel sein. Ich würde in diesem Fall die Notwendigkeit der ID-Spalte überhaupt in Frage stellen.

Die beste Wahl für den Clustered-Index hängt stark davon ab, wie die Tabelle abgefragt wird. Wenn die Mehrheit der Abfragen von USERID stammt, sollte es wahrscheinlich ein eindeutiger Clustered-Index (oder Clustered-Unique-Constraint) und die Spalte ID nicht-Clustered sein.

Beachten Sie, dass der Clustered-Indexschlüssel implizit in allen nicht gruppierten Indizes als Zeilenlokalisierer enthalten ist. Die Implikation ist, dass nicht gruppierte Indizes Abfragen und Blätterknoten des nicht gruppierten Indexblattes wahrscheinlicher abdecken.