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;