Grundsätze der SQL-Abfrageoptimierung

Indexierung & Statistiken

Indizes sind das wirkungsvollste Mittel zur Beschleunigung von SQL-Abfragen. Fehlt ein geeigneter Index, liest SQL Server bei jeder Abfrage alle Zeilen der Tabelle – ein sogenannter Table Scan. Bei großen Tabellen ist das der häufigste Grund für schlechte Laufzeiten.

Funktionen auf indizierten Spalten vermeiden

Wird eine Funktion direkt auf eine indizierte Spalte angewendet, kann SQL Server den Index nicht nutzen. Der Optimizer muss dann jede Zeile einzeln auswerten – ein vollständiger Scan ist die Folge. Die Lösung: den Wert transformieren, nicht die Spalte.

SELECT *
FROM Orders
WHERE YEAR(OrderDate) = 2024

SELECT *
FROM Orders
WHERE OrderDate >= '2024-01-01'
  AND OrderDate < '2025-01-01'

Index-Typen im Überblick

Covering Index mit INCLUDE

Ein Key Lookup entsteht, wenn SQL Server nach einem Index Seek noch zusätzliche Spalten aus der Basistabelle nachladen muss. Das lässt sich durch Aufnahme dieser Spalten in den Index mit INCLUDE verhindern.

-- Abfrage, die einen Key Lookup erzeugt:
SELECT CustomerID, CompanyName, ContactEmail
FROM Customers
WHERE Region = 'Bayern';

-- Covering Index: Suchspalte als Schlüssel, restliche als INCLUDE
CREATE NONCLUSTERED INDEX IX_Customers_Region
  ON Customers (Region)
  INCLUDE (CustomerID, CompanyName, ContactEmail);
GO

Statistiken und Fragmentierung

SQL Server verwendet Statistiken, um die Anzahl der betroffenen Zeilen zu schätzen und darauf basierend den besten Execution Plan zu wählen. Veraltete Statistiken führen zu falschen Schätzungen – und damit zu schlechten Plänen.

-- Statistiken für eine Tabelle aktualisieren
UPDATE STATISTICS Orders WITH FULLSCAN;

-- Alle Statistiken der Datenbank aktualisieren
EXEC sp_updatestats;

-- Fragmentierung aller Indizes prüfen
SELECT
  OBJECT_NAME(ips.object_id) AS Tabelle,
  i.[name] AS Indexname,
  ips.avg_fragmentation_in_percent AS Fragmentierung_Pct
FROM sys.dm_db_index_physical_stats
     (DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
INNER JOIN sys.indexes i
  ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.avg_fragmentation_in_percent > 10
ORDER BY Fragmentierung_Pct DESC;

Abfragestruktur

Die Formulierung einer Abfrage beeinflusst direkt, welchen Execution Plan der Optimizer wählt. Kleine syntaktische Unterschiede können dabei über Index-Nutzung oder vollständigen Table Scan entscheiden.

SELECT * vermeiden

Das Sternchen liest alle Spalten – auch breite Textfelder (NVARCHAR(MAX)) oder Binärspalten, die für die Abfrage irrelevant sind. Das erhöht I/O und Netzwerklast und verhindert die Nutzung von Covering Indexes.

SELECT *
FROM Customers
WHERE Region = 'Bayern'

SELECT CustomerID,
    CompanyName,
    ContactEmail
FROM Customers
WHERE Region = 'Bayern'

CTE, Subquery oder temporäre Tabelle?

CTEs (Common Table Expressions) verbessern die Lesbarkeit erheblich. SQL Server führt sie jedoch meist inline aus – das bedeutet, das Ergebnis wird bei mehrfacher Referenzierung im selben Query unter Umständen mehrfach berechnet. Für große Zwischenergebnisse, die mehrfach verwendet werden, sind temporäre Tabellen oft die bessere Wahl, da sie eigene Statistiken und Indizes erhalten können.

-- CTE: gut lesbar, sinnvoll bei einmaliger Verwendung
WITH TopCustomers AS (
  SELECT CustomerID, SUM(Amount) AS Total
  FROM Orders
  GROUP BY CustomerID
  HAVING SUM(Amount) > 10000
)
SELECT c.CompanyName, tc.Total
FROM TopCustomers tc
JOIN Customers c ON tc.CustomerID = c.CustomerID;

-- Temporäre Tabelle: besser bei Wiederverwendung oder großen Ergebnismengen
SELECT CustomerID, SUM(Amount) AS Total
INTO #TopCustomers
FROM Orders
GROUP BY CustomerID
HAVING SUM(Amount) > 10000;

-- Index auf der Temp-Tabelle verbessert nachfolgende JOINs
CREATE INDEX IX_TC ON #TopCustomers (CustomerID);

SELECT c.CompanyName, tc.Total
FROM #TopCustomers tc
JOIN Customers c ON tc.CustomerID = c.CustomerID;

DROP TABLE #TopCustomers;

Explizite JOINs verwenden

Die veraltete Syntax mit impliziten Joins (Komma-getrennte Tabellen in FROM mit Join-Bedingung in WHERE) ist schwerer zu lesen und fehleranfälliger – Cross Joins entstehen leicht versehentlich, wenn eine Bedingung vergessen wird.

SELECT o.OrderID, c.CompanyName
FROM Orders o, Customers c
WHERE o.CustomerID = c.CustomerID
  AND o.Status = 'Open'

SELECT o.OrderID, c.CompanyName
FROM Orders o
INNER JOIN Customers c
  ON o.CustomerID = c.CustomerID
WHERE o.Status = 'Open'

Häufige Stolperstellen

Execution Plan Analyse

Der Execution Plan zeigt, wie SQL Server eine Abfrage intern ausführt: welche Indizes verwendet werden, wie Tabellen verknüpft werden und wo der größte Anteil der Gesamtkosten entsteht. Das Lesen von Plänen ist die effektivste Methode zur Diagnose von Leistungsproblemen.

Plan anzeigen lassen

-- Geschätzter Plan (kein Ausführen erforderlich) – SSMS: Strg+L
SET SHOWPLAN_XML ON;
GO
SELECT OrderID, Amount FROM Orders WHERE CustomerID = 42;
GO
SET SHOWPLAN_XML OFF;

-- Tatsächlicher Plan (nach Ausführung) – SSMS: Strg+M, dann F5
-- Alternativ: I/O- und Zeit-Statistiken im Nachrichtenbereich
SET STATISTICS IO ON;
SET STATISTICS TIME ON;
GO
SELECT OrderID, Amount FROM Orders WHERE CustomerID = 42;
GO
SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;

Verarbeitungsablauf im Optimizer

Die wichtigsten Plan-Operatoren

Warnzeichen im Plan

Teuerste Abfragen aus dem Plan Cache

Die DMVs sys.dm_exec_query_stats und sys.dm_exec_sql_text liefern die aktuell teuersten Abfragen direkt aus dem Plan Cache – ein idealer Startpunkt für die systematische Optimierung.

SELECT TOP 10
  qs.total_worker_time / qs.execution_count AS avg_cpu_us,
  qs.total_logical_reads / qs.execution_count AS avg_logical_reads,
  qs.execution_count,
  SUBSTRING(qt.[text], (qs.statement_start_offset / 2) + 1,
    ((CASE qs.statement_end_offset
        WHEN -1 THEN DATALENGTH(qt.[text])
        ELSE qs.statement_end_offset
      END - qs.statement_start_offset) / 2) + 1) AS statement_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY avg_cpu_us DESC;