SQL Server Execution Plan – Operatoren erklärt

Execution Plan Index Seek Index Scan Key Lookup Table Scan

Execution Plan Operatoren
verstehen und bewerten

Seek, Scan, Lookup – was SQL Server im Hintergrund tut und wie man anhand dieser Operatoren Performance-Engpässe gezielt identifiziert.

Seek Gezielter Zugriff über den Indexbaum
Scan Sequenzielles Lesen aller Einträge
Lookup Nachladen einer einzelnen Zeile per Verweis
01
Seek

Index Seek / Clustered Index Seek

Was passiert

SQL Server navigiert im B-Tree des Index direkt zu den gesuchten Schlüsselwerten. Anschließend werden die Blattseiten in der verlinkten Liste traversiert, um alle Treffer zu sammeln – nur die relevanten Seiten werden gelesen.

Wann verwendet
  • WHERE-Bedingungen mit hoher Selektivität (ID = 42)
  • Bereichsfilter auf indizierten Spalten (BETWEEN, >=)
  • JOIN ON indizierte Spalten
Optimal. Der Index Seek ist die effizienteste Zugriffsart – nur die tatsächlich benötigten Seiten werden gelesen. Achtung Residual Predicate: Wenn der Index zwar für die Suche genutzt wird, auf Blattebene aber zusätzliche Filter ausgewertet werden müssen (weil nicht alle benötigten Spalten im Index enthalten sind), kann das die Performance spürbar verschlechtern. Im Plan erkennbar als „Predicate" unterhalb des Seek-Operators.

02
Scan

Index Scan / Clustered Index Scan

Was passiert

Der gesamte Index wird sequenziell in der Reihenfolge seiner Blattseiten gelesen. Im Gegensatz zum Table Scan erfolgt der Zugriff geordnet – aber alle Einträge werden verarbeitet, unabhängig davon, wie viele Treffer die Abfrage letztlich liefert.

Wann verwendet
  • Abfragen ohne oder mit schwach selektiver WHERE-Klausel
  • ORDER BY entspricht exakt der Index-Reihenfolge (Scan statt Sort)
  • Statistiken deuten darauf hin, dass ein Großteil der Zeilen benötigt wird
Situationsabhängig. Bei kleinen Tabellen oder wenn tatsächlich alle Zeilen benötigt werden, ist ein Scan sinnvoll und effizient. Bei großen Tabellen mit einer selektiven WHERE-Klausel ist er ein Hinweis auf einen fehlenden oder nicht nutzbaren Index.

03
Lookup

Key Lookup (Clustered)

Was passiert

Nach einem Zugriff über einen Non-Clustered Index fehlen Spalten, die nicht im Index enthalten sind. Für jede gefundene Zeile wird über den Primärschlüssel (Clustered Index) die vollständige Zeile aus der Basistabelle nachgeladen.

Wann verwendet
  • Non-Clustered Index wird für die Suche genutzt
  • Die SELECT-Liste oder WHERE-Bedingung enthält Spalten, die nicht im Index liegen
  • Kein Covering Index vorhanden
Kritisch bei vielen Treffern. Jeder Lookup ist ein zusätzlicher logischer Lesevorgang. Bei wenigen Zeilen (z.B. < 100) akzeptabel. Bei tausenden Treffern wird die Operation zum Flaschenhals. Abhilfe: Covering Index mit INCLUDE, der alle benötigten Spalten enthält – dann entfällt der Lookup vollständig.

04
Lookup

RID Lookup (Heap)

Was passiert

Das Gegenstück zum Key Lookup – aber auf einer Heap-Tabelle (ohne Clustered Index). Der Non-Clustered Index speichert als Zeiger eine RID (Row Identifier), bestehend aus Datei-, Seiten- und Zeilennummer. Mit dieser RID wird die Zeile direkt aus der Heap-Tabelle geholt.

Wann verwendet
  • Zugriff über Non-Clustered Index auf eine Heap-Tabelle
  • Nicht alle angeforderten Spalten sind im Index enthalten
  • Tabelle hat keinen Clustered Index (Primary Key fehlt)
Ähnlich problematisch wie der Key Lookup. Jeder Treffer erfordert einen separaten Zugriff auf die Heap-Seite. Zusätzliches Risiko: Bei Heap-Tabellen können Forwarding Pointers entstehen, wenn Zeilen durch Updates auf andere Seiten verschoben werden – das erhöht den I/O weiter. Lösung: Clustered Index anlegen oder Covering Index erweitern.

05
Scan

Table Scan

Was passiert

Die gesamte Tabelle wird – unabhängig von Indizes – vollständig und in physischer Speicherreihenfolge gelesen. Jede Zeile wird gegen die WHERE-Bedingung geprüft. Der Table Scan tritt nur bei Heap-Tabellen auf; hat die Tabelle einen Clustered Index, heißt die entsprechende Operation Clustered Index Scan.

Wann verwendet
  • Kein nutzbarer Index vorhanden (Heap-Tabelle)
  • WHERE-Bedingung nicht indizierbar (Funktion auf Spalte, Typkonvertierung)
  • Optimizer entscheidet: Scan günstiger als viele Einzelzugriffe (sehr kleine Tabellen oder kaum selektive Filter)
Meist teuerste Operation auf großen Tabellen. Alle Zeilen müssen gelesen und gegen die WHERE-Klausel geprüft werden – maximale I/O- und CPU-Last. Auf großen produktiven Tabellen ist ein Table Scan ein klares Warnsignal. Abhilfe: Geeigneten Index anlegen, Heap-Tabelle mit Clustered Index versehen, Abfragestruktur überprüfen.

Zusammenfassung

Operatoren auf einen Blick

Die folgende Tabelle gibt einen Überblick über alle fünf Operatoren, ihre typische Performance-Bewertung und die häufigste Gegenmaßnahme bei Problemen.

Operator Zugriffsmuster Tabellen-Typ Bewertung Gegenmaßnahme
Index Seek Gezielt, B-Tree-Navigation Mit CI oder NCI Optimal Residual Predicate prüfen
Index Scan Sequenziell, vollständig Mit CI oder NCI Situationsabhängig Selektivität der WHERE-Klausel erhöhen
Key Lookup Einzelzugriff per PK Mit Clustered Index Kritisch bei vielen Zeilen Covering Index mit INCLUDE
RID Lookup Einzelzugriff per RID Heap (kein CI) Kritisch bei vielen Zeilen Clustered Index anlegen
Table Scan Vollständig, physisch Heap (kein CI) Warnsignal Index anlegen, Abfrage prüfen

Plan lesen in SSMS

In SQL Server Management Studio lässt sich der Execution Plan grafisch anzeigen. Bewegt man die Maus über einen Operator, erscheint ein Tooltip mit detaillierten Informationen:

Estimated vs. Actual Rows: Die wichtigste Kennzahl im Plan. Weichen geschätzte und tatsächliche Zeilenzahl stark voneinander ab, sind die Statistiken veraltet oder es liegt ein Parametersniffing-Problem vor. Beides führt dazu, dass der Optimizer einen suboptimalen Plan wählt.
Tooltip-FeldBedeutung
Estimated RowsVom Optimizer auf Basis der Statistiken geschätzte Treffermenge
Actual RowsTatsächlich verarbeitete Zeilen (nur im tatsächlichen Plan)
Seek PredicateBedingung, die direkt über den B-Tree navigiert – effizient
PredicateFilter, der auf Blattebene nach dem Seek ausgewertet wird – Residual Predicate, kann teuer sein
Output ListSpalten, die der Operator an den nächsten Schritt weitergibt
Estimated Subtree CostRelative Kosten des Operators und seiner Kinder – Grundlage für die Pfeildickendarstellung
Missing Index Hint: SQL Server zeigt im Plan gelegentlich einen Hinweis auf einen fehlenden Index. Dieser Vorschlag sollte analysiert, aber nicht blind umgesetzt werden – zu viele Indizes verlangsamen INSERT/UPDATE/DELETE und erhöhen den Wartungsaufwand. Immer die tatsächliche Abfrage-Workload berücksichtigen.
MS SQL Server · Execution Plan Operatoren · Leitfaden