nicht gruppierte Indizes: Unique Index mit Primärschlüssel vs Non-Unique-Index ohne Primärschlüssel

Question

Die API Ich bin mit Indizes auf einer Tabelle erstellen, um alle nicht gruppierten Indizes als eindeutiger Index erstellt, die den Primärschlüssel enthält.

So die folgende Tabelle:

CREATE TABLE Person 
(
    [PersonID] INT NOT NULL PRIMARY KEY, -- clustered key on this col. 
    [First Name] VARCHAR(50), 
    [Last Name] VARCHAR(50), 
    [Other Columns] VARCHAR(50) 
) 

Das SQL-Statement für einen nicht gruppierten Index durch die API so etwas erstellt aussieht:

CREATE UNIQUE NONCLUSTERED INDEX KeyName 
ON Person ([First Name], [Last Name], [PersonID]) 

den Primärschlüssel im Index Indem es ist sichergestellt, dass alle Einträge eindeutig sind.

Persönlich würde ich den Index wie folgt geschaffen:

CREATE NONCLUSTERED INDEX KeyName2 
ON Person ([First Name], [Last Name]) 

ich verwendet, um die folgenden statment zweimal auf einem Tisch über 21 Millionen Datensätze enthält. Ich hatte immer nur einen der Indizes aktiv.

SELECT * 
FROM Person 
WHERE [First Name] = 'John' 
AND [Last Name] = 'Doe' 

Die "Geschätzte CPU-Kosten", "Geschätzte E/A-Kosten", "Geschätzte Operator Cost" und "Geschätzte Subtree Cost" waren genau die gleichen, egal welchen Index/deaktiviert wurde aktiviert.

Mein Verständnis von nicht gruppierten Indizes ist, dass der Primärschlüssel nicht auf die Daten verwendet wird sowieso abzurufen, aber einige Zeilennummer, die SQL-Server weist unabhängig. Gibt es also irgendwelche Vorteile, den UNIQUE-Index über den NON-UNIQUE-Index zu verwenden?

Ich würde vermuten, dass der UNIQUE-Index mehr Speicherplatz in Anspruch nimmt, da es eine weitere Spalte enthält. Deshalb würde ich die letztere Version bevorzugen.

Verwenden von SQL-Server 2012

Answer 1

Wenn PersonID Ihr Primärschlüssel ist, gibt es keine Speicher Unterschied zwischen

CREATE NONCLUSTERED INDEX KeyName 
ON Person ([First Name], [Last Name]) 

und

CREATE NONCLUSTERED INDEX KeyName2 
ON Person ([First Name], [Last Name], [PersonID]) 

Die PersonID implizit KeyName hinzugefügt wird, zu identifizieren, die Datenzeile.

Zusätzlich

CREATE UNIQUE NONCLUSTERED INDEX KeyName3 
ON Person ([First Name], [Last Name], [PersonID) 

und

CREATE NONCLUSTERED INDEX KeyName4 
ON Person ([First Name], [Last Name], [PersonID]) 

sind ebenfalls funktional identisch. Immer wenn der Primärschlüssel explizit als Schlüsselspalte enthalten ist, ist der Index technisch ein eindeutiger Index, auch wenn er nur durch den Primärschlüsselwert erzwungen wird. Das Hinzufügen des eindeutigen Qualifiers zu KeyName3 ist eine Verschwendung von Ressourcen, da SQL Server immer noch die Eindeutigkeit der Kombination aller drei Spalten überprüft, was bereits durch das Vorhandensein des Primärschlüssels gewährleistet ist.

Der Clustering-Schlüssel wird in jedem nicht gruppierten Index enthält die Datenzeilen in dem gruppierten Index zu zeigen. Wenn der Clusterschlüssel der Primärschlüssel oder ein eindeutiger Schlüssel ist, wird der Schlüsselwert zur Identifizierung der Datenzeile verwendet. Wenn der Clusterschlüssel kein eindeutiger Wert ist, fügt SQL Server jeder Datenzeile einen eindeutigen Wert hinzu, damit sie identifiziert werden kann. Dies ist jedoch keine echte Zeilennummer, da ein Padding vorhanden ist, mit dem zusätzliche Zeilen eingefügt/gelöscht werden können.Dieser zusätzliche Wert wird nach den expliziten Indexschlüsseln für Sortierzwecke betrachtet.

Wenn kein Clustered-Index (ein Heap) vorhanden ist, wird ein impliziter eindeutiger Wert verwendet, um auf die Datenzeile zu zeigen. Ohne einen Indexschlüssel zum Sortieren der Daten ändern die Zeilen die Reihenfolge jedoch nie, so dass keine Auffüllung erfolgt und der eindeutige Wert tatsächlich eine Zeilennummer ist.