SQL Server: Warum läuft meine Abfrage plötzlich langsam?

Jeder DBA kennt diese Situation: „Warum ist meine Abfrage auf einmal so langsam?“ Noch gestern lief sie in unter einer Sekunde, und heute braucht sie 15 oder mehr. Die Überraschung ist oft groß, die Ursachen aber meist sehr technisch. Bei einer SQL Server langsame Abfrage gibt es verschiedene Ursachen. In diesem Beitrag gebe ich einen umfassenden Überblick darüber, welche typischen Gründe hinter einer plötzlich langsamen SQL-Abfrage stecken können und wie du systematisch an die Fehlersuche herangehst.

Die Liste möglicher Ursachen ist lang und reicht von simplen Flüchtigkeitsfehlern bis zu schwer auffindbaren Infrastrukturproblemen:

• Locks oder Blocks
• Parameter Sniffing
• Veraltete oder falsche Statistiken
• Veränderte Ausführungspläne
• Speicher- oder IO-Engpässe
• Threadpool-Erschöpfung
• Fehlerhafte oder geänderte Indizes
• Netzwerkaussetzer
• Vergessene Transaktionen oder fehlende EXEC
• Probleme bei paralleler Ausführung
• Änderungen an Konfigurationen (MaxDOP, Cost Threshold etc.)

1. Locks, Blocks und offene Transaktionen

Ein häufiger Klassiker: Eine andere Session hält gerade einen exklusiven Lock auf eine Ressource, die deine Abfrage benötigt. Das führt zu Wartezeiten, die in der Benutzeroberfläche wie „Langsamkeit“ wirken, obwohl die Abfrage selbst gar nicht ineffizient ist.

Locks sind Schutzmechanismen, die SQL Server nutzt, um gleichzeitige Zugriffe zu koordinieren und Datenkonsistenz zu gewährleisten. Es gibt unterschiedliche Lock-Typen, etwa Shared Locks für Lesevorgänge oder Exclusive Locks für Schreibzugriffe. Wenn eine Session einen Lock hält und eine andere dieselbe Ressource benötigt, entsteht ein Block. Blocks machen sich bemerkbar durch blockierte Prozesse, „hängende“ Abfragen und Wartezeiten – obwohl technisch keine Systemauslastung vorliegt.

Prüfen mit:

SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;

Oder direkt über sp_WhoIsActive – mein bevorzugtes Tool für genau solche Analysen.

Ein oft übersehener Fall: Eine Anwendung startet BEGIN TRAN und vergisst das COMMIT. Die Locks bleiben bestehen, teilweise stundenlang.

2. Parameter Sniffing und suboptimale Ausführungspläne

SQL Server speichert beim ersten Aufruf einer Stored Procedure den Ausführungsplan basierend auf den übergebenen Parametern. Wird später ein anderer Wert verwendet, kann der ursprünglich erstellte Plan ungeeignet sein – besonders dann, wenn sich die Datenverteilung stark unterscheidet. Das nennt man Parameter Sniffing.

Ein häufiger Fall: Für einen „kleinen“ Parameterwert wird ein effizienter Plan mit Index Seek erstellt. Ruft jemand die Prozedur später mit einem „großen“ Wert auf, der viel mehr Daten liefert, bleibt der alte Plan bestehen – und ist plötzlich ungeeignet. Das führt zu Table Scans, langer Laufzeit und Speicherproblemen.

Typische Anzeichen:

• Gleiche Prozedur, aber stark unterschiedliche Laufzeiten je nach Parameter
• Execution Plan zeigt unerwartete Table Scans oder Nested Loops bei großer Datenmenge
• Estimated Rows stimmen nicht mit Actual Rows überein (große Abweichung)

So erkennst du Parameter Sniffing im Execution Plan:

• Im Ausführungsplan auf den Abschnitt „Parameter List“ achten
• Estimated vs. Actual Rows vergleichen – starke Unterschiede deuten oft auf ein Planproblem hin
• Mit dem Query Store kannst du verschiedene Pläne einer Abfrage vergleichen – besonders hilfreich, wenn es mal schnell und mal langsam läuft

Lösungen:

• OPTION (RECOMPILE) verwenden – dadurch wird der Plan bei jedem Aufruf neu erstellt
• Parameter in der Prozedur lokal neu zuweisen (DECLARE @p INT = @OriginalP) – verhindert das Sniffing
• Query Store nutzen, um Pläne zu beobachten und ggf. manuell festzulegen (Plan Forcing)
• Stored Procedures bei bekannten Mustern gezielt aufsplitten (z. B. SP für „kleine“ und „große“ Werte getrennt)

Parameter Sniffing ist ein subtiler, aber mächtiger Performance-Killer – und leider einer der am schwierigsten zu erkennenden. Es lohnt sich, sich damit im Detail zu beschäftigen, gerade wenn sich Performanceprobleme nicht logisch erklären lassen.

Typische Anzeichen:

• Gleiche Prozedur, aber stark unterschiedliche Laufzeiten je nach Parameter
• Abfrage springt plötzlich auf Table Scans

Lösungen:

• OPTION (RECOMPILE) verwenden
• Parameter in der Prozedur lokal neu zuweisen
• Query Store einsetzen, um Pläne zu beobachten und ggf. zu forcieren

3. Veraltete Statistiken oder veränderte Datenverteilung

Bei stark wachsenden Tabellen oder saisonalen Daten kann es passieren, dass Statistiken nicht mehr repräsentativ sind – die Schätzungen für Zeilenanzahl und Verteilung sind dann schlicht falsch.

Prüfen mit:

SELECT name, STATS_DATE(object_id, stats_id) AS LastUpdated FROM sys.stats;

Maßnahmen:

• Manuelles UPDATE STATISTICS
• Eventuell FULLSCAN statt Sampling
• Regelmäßige Wartung (z. B. via Ola Hallengren Skript)

4. Ressourcenengpässe: IO, Arbeitsspeicher, Threads

• IO: Speicher-Subsysteme mit hoher Latenz, defekte SSDs oder Contention auf LUNs führen zu drastischen Leistungseinbrüchen.
• Memory Pressure: Wenn der Buffer Cache zu klein wird, muss SQL Server ständig Seiten von der Platte nachladen. Das kostet Zeit.
• Threadpool-Erschöpfung: Kein Worker Thread verfügbar = Warten. Besonders kritisch bei vielen parallelen Anfragen oder schlecht konfiguriertem MaxDOP.

Warten analysieren mit:

SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;

Zusätzlich prüfen:

SELECT * FROM sys.dm_exec_requests WHERE status = 'suspended';

5. Indizes: Entfernt, verändert oder ineffizient

Wenn sich jemand entschließt, einen „unnötigen“ Index zu löschen – ohne die Auswirkungen zu prüfen – hat man schnell eine unerwünschte Planänderung.

Auch fragmentierte Indizes oder geänderte Spaltenreihenfolgen können Abfragen ausbremsen. Selbst kleine Veränderungen in der Index-Struktur oder im Fillfactor haben potenziell große Auswirkungen auf die Performance.

Auf meinem Blog findest du dazu auch weiterführende Beiträge – etwa zur Index-Maintenance mit Ola Hallengren oder zur richtigen Spaltenreihenfolge in Indexdefinitionen. Beide Themen spielen bei der nachhaltigen Performance-Optimierung eine zentrale Rolle.

Empfehlung:

• Rebuild oder Reorganize regelmäßig durchführen
• Änderungen an Indizes dokumentieren
• Query Store verwenden, um Planvergleiche durchzuführen

6. Parallelismus – zu viel oder zu wenig

SQL Server entscheidet automatisch, ob eine Abfrage parallel ausgeführt wird. Diese Entscheidung basiert auf Faktoren wie geschätztem Ressourcenbedarf, Kosten des Ausführungsplans und aktuellen Systemressourcen. Probleme entstehen dann, wenn die Systemkonfiguration (z. B. max degree of parallelism oder cost threshold for parallelism) nicht zur Workload passt oder andere Prozesse bereits viele CPU-Kerne belegen.

Mögliche Ursachen sind beispielsweise falsch gesetzte MaxDOP-Werte, übermäßige Parallelisierung durch komplexe Abfragen oder eine unzureichende Aufteilung durch das SQL Server Scheduling-System. Auch die SQL Server Edition kann Einfluss auf die Parallelismus-Funktionalität nehmen.

Die Auswirkungen können gravierend sein: Entweder wird unnötig viel CPU verbraucht, weil zu viele parallele Threads gestartet werden, oder die Abfrage wird trotz hohem Datenvolumen seriell ausgeführt und damit unnötig langsam. In beiden Fällen entsteht das Gefühl, dass der SQL Server „einfach langsam“ ist – obwohl die Ursache tiefer liegt. Je nach Systemauslastung, MaxDOP-Einstellung und Abfragekomplexität kann das:

• zu übermäßiger CPU-Nutzung führen (zu viele parallele Threads)
• oder unnötig seriell laufen, obwohl eine Parallelisierung sinnvoll wäre

Prüfe mit sys.dm_exec_query_stats und sys.dm_exec_query_plan, ob und wie viele Threads verwendet wurden.

Überdenke Einstellungen wie:

• Cost Threshold for Parallelism
• max degree of parallelism
• Ressourcen-Governor oder Workload Group Settings

7. Netzwerke und Tools: Wenn die Ursache außerhalb liegt

• DNS-Probleme, VPN-Latenz, Firewalls oder defekte Switche sorgen für seltsame Latenzen
• SQL Server ist „schnell“, aber das Frontend (z. B. SSMS, Drittanbieter-Tool) zeigt Verzögerungen
• Klassischer Fehler: Ctrl+E zeigt nur den Plan – F5 muss es sein 😉

Fazit: Nicht raten – messen und verstehen!

Eine plötzlich langsame Abfrage hat immer eine Ursache – manchmal simpel, manchmal tief verborgen. Wichtig ist, strukturiert vorzugehen und sich nicht auf Bauchgefühl zu verlassen.

• Locks und Blocks prüfen
• Ausführungspläne vergleichen
• Ressourcenüberwachung aktivieren
• Index- und Statistikpflege ernst nehmen
• Query Store aktiv nutzen

Du brauchst Unterstützung bei der Analyse oder willst deine Umgebung absichern? Melde dich gern – ich helfe dir, die Ursache zu finden, bevor es die Nutzer merken. 😉

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.