Primary Key und Indizes im MS SQL Server lösen zwei unterschiedliche Aufgaben: Ein Primary Key legt fest, welcher Schlüssel eine Tabellenzeile eindeutig identifiziert. Ein Index stellt Daten so bereit, dass SQL Server bestimmte Abfragen effizienter ausführen kann. Beides hängt zusammen, denn SQL Server legt zur Durchsetzung eines Primary Keys automatisch einen eindeutigen Index an. Trotzdem ist nicht jeder Index ein Primary Key, und ein zusätzlicher Index ist nicht für jede Abfrage sinnvoll.

Dieser Artikel erklärt die Unterschiede, zeigt lauffähige T-SQL-Beispiele und hilft dir bei der Entscheidung, welche Spalten du indizierst. Die Beispiele verwenden lokale temporäre Tabellen, damit du keine vorhandenen Anwendungstabellen verändern musst.

Was ist ein Primary Key im SQL Server?

Der Primary Key (Primärschlüssel) ist eine Einschränkung, auch Constraint genannt. Er garantiert, dass jeder Schlüsselwert beziehungsweise jede Schlüsselkombination nur einmal vorkommt. Die beteiligten Spalten dürfen nicht NULL sein. Pro Tabelle gibt es höchstens einen Primary Key; dieser kann aus einer oder mehreren Spalten bestehen.

Wichtig ist die genaue Bedeutung von „eindeutig“: Zwei Kunden können denselben Vor- und Nachnamen besitzen. Solange ihre Kundennummern verschieden sind, verletzt das den Primary Key nicht. Er verhindert doppelte Schlüsselwerte, nicht jede inhaltlich ähnliche oder identische Zeile in anderen Spalten.

Auch eine IDENTITY-Spalte ist nicht automatisch ein Primary Key. IDENTITY erzeugt Werte; die Eindeutigkeit und Schlüsselrolle definierst du separat über einen entsprechenden Constraint.

Primary Key und Indizes im MS SQL Server: die Verbindung

SQL Server erzwingt einen Primary Key durch einen automatisch angelegten eindeutigen Index. Wenn die Tabelle noch keinen Clustered Index hat und du keinen Indextyp angibst, wird dieser Index standardmäßig clustered. Du kannst den Primary Key aber auch ausdrücklich als NONCLUSTERED definieren, etwa wenn ein anderer Schlüssel besser für den Clustered Index geeignet ist.

Ein Index ist dagegen zunächst eine Datenstruktur für den Zugriff auf Zeilen. Ein normaler, nicht eindeutiger Index lässt gleiche Schlüsselwerte zu. Ein UNIQUE-Index erzwingt zusätzlich Eindeutigkeit, ist dadurch aber noch kein Primary Key. Die Microsoft-Dokumentation zu Primary und Foreign Keys beschreibt diese Regeln im Detail.

Beispiel: Kundentabelle mit Primary Key erstellen

Führe den folgenden Block in einem SQL-Server-Abfragefenster aus. Er erstellt eine lokale temporäre Tabelle in deiner Sitzung und fügt drei Testkunden ein. Beim erneuten Ausführen wird nur diese Übungstabelle neu erstellt:

IF OBJECT_ID('tempdb..#Kunden') IS NOT NULL
    DROP TABLE #Kunden;

CREATE TABLE #Kunden (
    KundenID int NOT NULL PRIMARY KEY CLUSTERED,
    Vorname nvarchar(50) NOT NULL,
    Nachname nvarchar(50) NOT NULL,
    Email nvarchar(255) NOT NULL,
    ErstelltAm date NOT NULL
);

INSERT INTO #Kunden
    (KundenID, Vorname, Nachname, Email, ErstelltAm)
VALUES
    (1, N'Anna', N'Weber', N'anna@example.com', '2026-01-10'),
    (2, N'Ben', N'Meier', N'ben@example.com', '2026-02-05'),
    (3, N'Clara', N'Weber', N'clara@example.com', '2026-03-12');

Die Spalte KundenID identifiziert jeden Kunden eindeutig. Der Name Weber darf mehrfach vorkommen. Ein weiterer Datensatz mit KundenID = 1 würde dagegen am Primary Key scheitern. Das N vor Textwerten kennzeichnet Unicode-Zeichenfolgen.

Die Tabelle bleibt nur für die aktuelle Verbindung verfügbar. Öffnest du eine neue Verbindung, musst du den Vorbereitungsblock erneut ausführen.

Zusammengesetzter Primary Key

Manchmal ist erst die Kombination zweier Spalten eindeutig. Bei Bestellpositionen kann dieselbe Positionsnummer in verschiedenen Bestellungen vorkommen:

CREATE TABLE #Bestellpositionen (
    BestellungID int NOT NULL,
    Positionsnummer int NOT NULL,
    Artikelnummer nvarchar(30) NOT NULL,
    Menge int NOT NULL,
    PRIMARY KEY (BestellungID, Positionsnummer)
);

Für dieselbe Bestellung darf jede Positionsnummer nur einmal vorkommen. Die Reihenfolge der Spalten im zusammengesetzten Schlüssel ist auch für die Nutzung des zugehörigen Index wichtig. Wähle sie nach Eindeutigkeit, Beziehungen und typischen Abfragen, nicht allein nach der Anzeige-Reihenfolge.

Clustered und Nonclustered Index unterscheiden

Bei einem Clustered Index liegen die Datenzeilen auf der Blattebene des Index; die Zeilen sind dort nach dem Indexschlüssel organisiert. Pro Tabelle kann es nur einen Clustered Index geben. Eine Tabelle ohne Clustered Index heißt Heap. Der Clustered Index legt jedoch keine garantierte Ausgabereihenfolge für SELECT fest: Wenn die Reihenfolge wichtig ist, verwende immer ORDER BY.

Ein Nonclustered Index ist eine separate Struktur mit Indexschlüsseln und einem Verweis auf die jeweilige Datenzeile. Auf einer Tabelle können mehrere Nonclustered Indizes liegen. Sie sind besonders nützlich, wenn Abfragen häufig nach bestimmten Spalten suchen oder sortieren. Ob SQL Server einen Index tatsächlich nutzt, entscheidet der Optimierer anhand der Abfrage und seiner Kostenschätzung.

Bei beiden Typen gilt: Indizes benötigen Speicher und müssen bei Änderungen an den betroffenen Daten gepflegt werden. Ein zusätzlicher Index kann Leseabfragen verbessern und gleichzeitig INSERT, UPDATE oder DELETE verteuern. Die Microsoft-Anleitung zum Indexdesign empfiehlt deshalb, Indizes an realen Abfragen auszurichten.

Nonclustered Index für eine häufige Suche anlegen

Angenommen, eine Anwendung sucht regelmäßig Kunden anhand der E-Mail-Adresse. Ein passender Index auf der Testtabelle könnte so aussehen:

CREATE NONCLUSTERED INDEX IX_Kunden_Email
ON #Kunden (Email)
INCLUDE (Vorname, Nachname);

Email ist die Schlüsselspalte des Index. Vorname und Nachname sind nur auf der Blattebene enthaltene INCLUDE-Spalten. Sie erweitern den Index für diese Abfrage, ohne Teil des Suchschlüssels zu sein:

SELECT KundenID, Vorname, Nachname
FROM #Kunden
WHERE Email = N'anna@example.com';

Die KundenID ist als Clustered-Schlüssel im Nonclustered Index ebenfalls verfügbar. Der Index kann damit alle Spalten dieser Abfrage liefern, ohne zusätzlich die Datenseiten der Tabelle zu lesen. Das nennt man einen abdeckenden Index. Auf der winzigen Übungstabelle wirst du dadurch wahrscheinlich keinen messbaren Geschwindigkeitsvorteil sehen; der Optimierer kann sogar einen Scan wählen. Das ist kein Fehler. Microsoft erklärt INCLUDE-Spalten und ihre Kosten ausführlicher.

Der oben angelegte Index ist nicht eindeutig. Wenn E-Mail-Adressen laut Fachregel nur einmal vorkommen dürfen, brauchst du zusätzlich eine passende Eindeutigkeitsregel, beispielsweise einen UNIQUE-Constraint oder einen eindeutigen Index. Entscheide das anhand der Datenregeln, nicht allein anhand der Suche.

Wie wählst du geeignete Indexspalten aus?

Der Ausgangspunkt ist die tatsächliche Abfrage. Häufige Suchbedingungen in WHERE, Verknüpfungen in JOIN und bestimmte Sortierungen in ORDER BY können von passenden Indexschlüsseln profitieren. Bei einem mehrspaltigen Index beeinflusst die Reihenfolge der Schlüsselspalten, welche Suchmuster er gut unterstützt.

  • Schmale Schlüssel bevorzugen: Breite Schlüssel verbrauchen mehr Speicher und erhöhen den Aufwand bei Änderungen.
  • Selektivität prüfen: Eine Suche, die nur wenige Zeilen liefert, profitiert oft eher von einem Index als eine Suche, die fast die ganze Tabelle zurückgibt.
  • INCLUDE sparsam einsetzen: Zusätzliche Spalten können Abfragen abdecken, vergrößern aber den Index.
  • Änderungen berücksichtigen: Jede zusätzliche Struktur kostet Platz und kann Schreibvorgänge verlangsamen.
  • Keine pauschalen Rezepte übernehmen: Ein Indextipp aus einer anderen Datenbank passt nicht zwangsläufig zu deinen Datenmengen und Abfragen.

Ein Foreign Key bekommt im SQL Server nicht automatisch einen eigenen Index. Solche Spalten sind dennoch oft gute Kandidaten, wenn sie häufig für Joins oder Prüfungen genutzt werden. Ob sich der zusätzliche Index lohnt, solltest du anhand der Arbeitslast prüfen.

Primary Key und Indizes im MS SQL Server prüfen

Für die Übungstabelle kannst du die vorhandenen Indizes über die Systemansicht sys.indexes anzeigen. Führe die Abfrage in derselben Verbindung aus, in der du #Kunden angelegt hast:

SELECT i.name,
       i.type_desc,
       i.is_unique,
       i.is_primary_key
FROM tempdb.sys.indexes AS i
WHERE i.object_id = OBJECT_ID('tempdb..#Kunden')
ORDER BY i.index_id;

Du solltest den automatisch erzeugten eindeutigen Clustered Index des Primary Keys und den zusätzlich angelegten Nonclustered Index sehen. Der Name des Primary-Key-Index wird bei dieser temporären Tabelle von SQL Server vergeben.

Ob ein Index eine langsame Abfrage verbessert, erkennst du nicht allein daran, dass er existiert. Prüfe den tatsächlichen Ausführungsplan einer repräsentativen Abfrage sowie Laufzeit und gelesene Seiten vor und nach einer Änderung. Bei sehr kleinen Tabellen kann ein Scan günstiger sein als ein Indexzugriff. Für die weiterführende Diagnose findest du auf IT-Fundus die Beiträge zur Analyse langsamer Abfragen mit Query Store und Ausführungsplänen sowie zur Indexnutzung und Wartung.

Häufige Fehler bei Primary Keys und Indizes

  • Primary Key mit fachlicher Eindeutigkeit verwechseln: Eine eindeutige Kundennummer verhindert keine doppelt erfasste Person. Solche Regeln musst du gesondert modellieren.
  • Clustered Index als Sortiergarantie ansehen: Nur ORDER BY garantiert die gewünschte Ergebnisreihenfolge.
  • Jede Spalte einzeln indizieren: Viele Indizes erhöhen Speicher- und Schreibaufwand und lösen nicht automatisch langsame Abfragen.
  • Indexwirkung ohne Messung behaupten: Datenmenge, Verteilung, Abfrage und Ausführungsplan entscheiden über den Nutzen.
  • Foreign Keys für automatisch indiziert halten: SQL Server legt für einen Foreign Key allein keinen Index an.

Häufige Fragen zu Primary Key und Indizes im MS SQL Server

Muss ein Primary Key ein Clustered Index sein?

Nein. Wenn noch kein Clustered Index existiert, ist CLUSTERED zwar die Voreinstellung. Du kannst den Primary Key aber ausdrücklich als NONCLUSTERED definieren und den Clustered Index auf einem anderen passenden Schlüssel anlegen.

Kann eine Tabelle mehrere Primary Keys haben?

Nein, nur einen. Dieser eine Primary Key darf jedoch mehrere Spalten umfassen. Zusätzliche Eindeutigkeitsregeln lassen sich mit UNIQUE-Constraints oder eindeutigen Indizes abbilden.

Ist ein Index auf der E-Mail-Adresse immer sinnvoll?

Nein. Er kann bei häufigen, selektiven Suchen helfen. Bei einer kleinen Tabelle oder seltenen Abfragen überwiegen womöglich Speicher- und Pflegekosten. Ob E-Mail-Adressen eindeutig sein müssen, ist außerdem eine fachliche Frage.

Fazit zu Primary Key und Indizes im MS SQL Server

Primary Key und Indizes im MS SQL Server gehören zusammen, haben aber verschiedene Zwecke: Der Primary Key sichert eindeutige, nicht leere Schlüsselwerte; Indizes unterstützen passende Datenzugriffe. Lege Schlüssel nach dem Datenmodell fest und ergänze weitere Indizes anhand konkreter Abfragen. Prüfe ihre Wirkung im Ausführungsplan, statt aus der bloßen Existenz eines Index auf bessere Leistung zu schließen.