SQL Server Optimierung — aus lahm wird schnell

Wer schon mal einen Tagesabschluss-Report 47 Minuten lang angestarrt hat, weiß: SQL Server Performance ist kein Luxusproblem. Sie ist der Unterschied zwischen Mitarbeitern, die arbeiten — und Mitarbeitern, die warten. Diese Seite zeigt dir, was bei der Optimierung von Microsoft SQL Server alles geht, in welcher Reihenfolge man rangeht, und woran ich erkenne, ob ein System schlicht falsch konfiguriert oder grundlegend krank ist.

Spoiler: Es ist fast immer falsch konfiguriert. Und das ist die gute Nachricht.

Was ist SQL-Server-Optimierung? SQL-Server-Optimierung bezeichnet die systematische Verbesserung der Performance, Stabilität und Effizienz einer Microsoft-SQL-Server-Instanz. Sie umfasst fünf Bereiche: Indizes, Statistiken, Query-Tuning, Konfiguration (Memory, MAXDOP, TempDB, Storage) sowie Wartung. Ziel ist nicht „möglichst schnell“, sondern „schnell genug, vorhersagbar und ohne nächtliche Anrufe“.

 

Die fünf Stellschrauben — der Überblick

Wer SQL Server optimieren will, hat genau fünf Bereiche, an denen es sich zu drehen lohnt. Alles andere ist Folklore. Wer nur an einer Stellschraube dreht, wird selten glücklich — die Bereiche hängen zusammen.

Abbildung 1: Die fünf Bereiche der SQL-Server-Optimierung — kein Ranking, sondern fünf gleichberechtigte Hebel.

Im Folgenden gehe ich jeden Bereich einmal durch. Wer es eilig hat: Indizes und Statistiken bringen in 80 Prozent der Fälle 80 Prozent des Effekts. Der Rest ist Feintuning und Hygiene.

1. Indizes — wo die meiste Zeit verloren geht

Indizes sind der einflussreichste Hebel überhaupt. Ein fehlender Clustered Index auf einer 80-Millionen-Zeilen-Tabelle macht aus einem Sekunden-Query einen Halbstunden-Job. Ein redundanter Index kostet Write-Performance und Wartungszeit. Beides kommt häufiger vor, als man denkt.

Typische Befunde in der Praxis

• Tabellen ohne Clustered Index („Heaps“) — meistens historisch gewachsen, niemand traut sich ran.
• Indizes, die seit Monaten kein einziges Read-Hit hatten, aber bei jedem Insert mitgepflegt werden müssen.
• Drei Indizes auf derselben Spaltenkombination mit minimal abweichenden Include-Spalten — alle drei werden gepflegt, einer wird genutzt.
• Fragmentierung von 80 Prozent und mehr, weil Reindex zuletzt unter Windows Server 2012 R2 lief.

Praxisbeispiel: Der eine fehlende Index Mittelständischer Maschinenbauer, Warenwirtschaft. Der Auftragsstatus-Report lief 12 Minuten, dreißigmal pro Tag, von dreißig Sachbearbeitern. Macht 180 Mannstunden Wartezeit pro Monat. Befund: Ein nicht vorhandener Index auf einer Statusspalte mit 28 distinct values. Die Query scannte jedes Mal 14 Millionen Zeilen. Maßnahme: Ein einzelner gefilterter Index. Aufwand: 6 Sekunden Implementierung, 18 Minuten Testlauf, 4 Stunden Doku und Übergabe. Ergebnis: Report-Laufzeit 9 Sekunden. Sachbearbeiter glücklich. Der CFO weniger — weil er sich fragte, warum das nicht schon vor drei Jahren jemand gemacht hat.

 

2. Statistiken — damit der Optimizer nicht rät

Der Query-Optimizer trifft seine Entscheidungen auf Basis von Statistiken. Sind die veraltet, plant er auf Basis von gestern — und das geht regelmäßig in die Hose. Veraltete Statistiken sind die Ursache Nummer eins für Pläne, die „über Nacht“ plötzlich katastrophal werden.

Was ich prüfe

• Wie alt sind die Statistiken? Default-Auto-Update reicht oft nicht — vor allem nicht bei großen Tabellen jenseits der Modification-Counter-Schwelle.
• Sind Auto-Update Stats und Auto-Create Stats überhaupt an? Antwort: häufiger nein, als man hofft.
• Wird Auto-Update Stats Async genutzt? Bei OLTP-Systemen oft eine gute Idee, bei DWH-Systemen eher nicht.
• Gibt es Filtered Statistics, wo sie sinnvoll wären? Meistens nicht, weil sie kaum jemand kennt.

Hinweis: Die fiese Falle der „guten“ Pläne Ein Query, der gestern in 200 ms lief, läuft heute 45 Sekunden — bei identischen Daten und identischer Last. Warum? Plan-Cache hat einen neuen Plan kompiliert, basierend auf veralteten Statistiken, und der ist plötzlich katastrophal. Parameter Sniffing nennt sich das Phänomen — und es ist einer der häufigsten Anrufe nach Mitternacht.

 

3. Query-Tuning — SARGable schreiben oder schweigen

Hier wird es persönlich. Indizes und Statistiken kann man dem System mit Routine beibringen — schlechte Queries müssen Menschen umschreiben. Das schmerzt, weil die Queries oft von der Anwendung kommen und der Hersteller „so etwas nicht ändert“.

Die Klassiker, die ich immer wieder sehe

• Funktionen auf indizierten Spalten: WHERE YEAR(BestellDatum) = 2024 macht jeden Index unbrauchbar. SARGable wäre WHERE BestellDatum >= ‚2024-01-01‘ AND BestellDatum < ‚2025-01-01‘.
• Implizite Datentyp-Konvertierungen: Die Anwendung sendet nvarchar, die Spalte ist varchar. Index wird ignoriert, alle freuen sich.
• SELECT * in Reports: Niemand braucht 47 Spalten, aber jeder zieht sie. Covering Indexes? Fehlanzeige.
• Korrelierte Subqueries, wo ein JOIN täte: Klassisch in handgeschriebenem Code aus der ORM-Welt.

Sarkasmus-Ecke: „Das hat aber immer funktioniert.“ Mein Lieblings-Satz im ersten Kunden-Termin. Übersetzung: „Das war früher mal schnell, als die Tabelle 200.000 Zeilen hatte. Jetzt sind es 87 Millionen, aber wir haben das Backup von 2018 nicht aufgehoben.“ Performance ist nicht etwas, das man einmal einstellt und dann läuft sie. Sie ist eine Disziplin, die mit dem System wächst — oder eben nicht.

 

4. Konfiguration & Hardware — die unsichtbare Bremse

Selbst die schönsten Indizes und sauberste Queries nützen wenig, wenn der SQL Server mit Default-Einstellungen aus dem Setup-Wizard läuft. Hier sind die typischen Verdächtigen:

Bereich	Häufiger Fehler	Korrektur
Max Server Memory	Default, also „alles“ — System schwankt	Konkret begrenzen, OS-Bedarf einkalkulieren
MAXDOP	0 (alle Cores parallel pro Query)	4 bis 8 je nach NUMA, Workload-abhängig
Cost Threshold for Parallelism	Default 5 — viel zu niedrig für heutige CPUs	Eher 30 bis 50
TempDB	Eine Datei, auf Systemplatte	Mehrere gleich große Files, separates Volume
Instant File Initialization	Aus, weil keiner das Recht zugewiesen hat	Service-Account: „Perform Volume Maintenance Tasks“
Power Plan	Balanced — CPUs takten herunter	High Performance, sowohl Windows als auch BIOS
Storage Layout	Daten, Log und TempDB auf einer LUN	Trennen, mindestens logisch — gerne auch physisch

 

Hinweis: Hardware ist nicht die erste Antwort Bevor neue Hardware gekauft wird, sollte die alte richtig konfiguriert sein. Ich habe mehr als einmal erlebt, dass nach einer Konfigurations-Säuberung der „dringend nötige“ neue Server für weitere zwei Jahre überflüssig war. Das hat den Einkauf nicht immer glücklich gemacht, den Geschäftsführer aber durchaus.

 

5. Wartung — die langweilige, lebenswichtige

Wartung ist der Teil, den niemand sehen will, der aber dafür sorgt, dass die ersten vier Punkte überhaupt wirken. Ein optimaler Index bringt nichts, wenn er nach drei Monaten zu 90 Prozent fragmentiert ist und niemand das merkt.

Was zu einer Wartungsroutine gehört

• Reindex/Reorganize regelmäßig — aber gezielt, nicht mit der Schrotflinte über alles
• Update Statistics, vor allem für Tabellen mit hoher Änderungsrate
• Backup-Strategie inklusive Verifikation — ein nie getestetes Backup ist ein Glücksspiel
• Integrity-Checks (DBCC CHECKDB) regelmäßig, nicht erst, wenn etwas blinkt
• Plan-Cache-Hygiene und Query-Store-Auswertung
• Monitoring, das mehr macht als „SQL läuft“ — Trends statt Schnappschüsse

Was Optimierung typischerweise bringt

„Wieviel schneller wird es denn?“ — die häufigste Frage im Erstgespräch. Die ehrliche Antwort: kommt drauf an, wie schlimm der Ausgangszustand ist. Werte aus echten Projekten der letzten Jahre:

Abbildung 2: Typische Effekte einer kompletten SQL-Server-Optimierung. Die Werte stammen aus realen Projekten — kein Marketing-Bingo.

Faktor 5 bis 15 ist in den meisten Projekten realistisch. Faktor 30 und mehr habe ich auch schon gesehen — das ist dann aber meistens der Befund: „War vorher einfach komplett kaputt“. Was nicht heißt, dass das angenehm zu hören ist.

Fallbeispiel: Musterwerk GmbH

Ausgangslage — Sondermaschinenbau, 320 Mitarbeiter Die Musterwerk GmbH betreibt eine ERP-Lösung auf SQL Server 2019. Der nächtliche Buchungslauf lief inzwischen bis nachmittags um 14 Uhr — und damit mitten in den Arbeitstag hinein. Die internen Argumente wechselten zwischen „neue Hardware kaufen“ und „auf die Cloud migrieren“. Bevor 250.000 Euro bewegt wurden, gab es einen Anruf bei mir.

 

Befund nach drei Tagen Analyse

• Max Server Memory: nicht gesetzt. Server hatte 192 GB RAM, SQL Server zog phasenweise 178 GB, Windows fing an zu pagen.
• Eine TempDB-Datei. Auf der Systemplatte. SSD, aber halt eine.
• Vier Indizes auf der größten Tabelle waren seit dem letzten Major-Update nie aktualisiert worden — Fragmentierung 94 Prozent.
• Die zentrale Buchungs-Stored–Procedure baute via Cursor zeilenweise um eine Tabelle mit 12 Millionen Datensätzen herum.

Maßnahmenpaket (in dieser Reihenfolge)

• Memory-Cap, MAXDOP und Cost Threshold korrekt setzen — eine Stunde, inklusive Restart-Fenster.
• TempDB-Layout: vier Files, separates Volume, korrekte Größen — ein Wartungsfenster.
• Reindex der drei kritischsten Tabellen plus Update Statistics — über das nächste Wochenende.
• Buchungs-Stored–Procedure umgeschrieben: Cursor raus, mengenorientiert rein — zwei Tage, inklusive Tests.

Ergebnis Buchungslauf vorher: durchschnittlich 6 Stunden 28 Minuten. Manchmal länger. Buchungslauf nachher: 1 Stunde 36 Minuten. Reproduzierbar. Investition: rund 6 Beratungstage. Geplante Hardware-Investition (250.000 Euro): gestrichen. Die Geschäftsführung hat mir zwei Wochen später nachgereicht, dass der nächtliche Anruf-Bereitschaftsdienst der IT-Abteilung zum ersten Mal seit Jahren ein ruhiges Wochenende hatte. Das war übrigens der Satz, der mir am meisten Freude gemacht hat.

 

Mein Vorgehen — wie ich Performance-Probleme angehe

Eine Optimierung ohne Messung ist Bastelei. Mein Vorgehen ist deshalb iterativ und beginnt immer mit Daten — nicht mit Vermutungen.

Abbildung 3: Performance-Tuning ist iterativ. Wer mit Schritt 3 anfängt, optimiert auf Verdacht — und macht Dinge oft schlimmer.

Was ich konkret messe

• Wait Statistics über einen repräsentativen Zeitraum (mindestens 24 Stunden, besser eine Woche)
• Top-Queries nach CPU, Reads, Writes und Duration — über den Query Store oder per DMV
• Perf-Counter-Trends — dafür gibt es bei mir das Collect-SqlPerf-Script.
• Schema-Inventar — fehlende Indizes, redundante Indizes, Heaps, Konfiguration

Was kostet schlechte SQL-Server-Performance eigentlich?

„Es geht ja gerade so“ ist eine teure Aussage. Hier ein paar Größenordnungen aus echten Projekten — vielleicht hilft die Rechnung beim nächsten Budget-Gespräch:

Effekt	Kosten pro Jahr (grob)	Vermeidbar durch
30 Sachbearbeiter warten täglich 20 min auf Reports	~ 85.000 €	Index- und Query-Optimierung
Nightly Job läuft bis 11 Uhr — IT-Bereitschaft jede Nacht	~ 40.000 €	Konfiguration und Statistiken
„Wir brauchen einen neuen, größeren Server“	60.000 – 250.000 €	Saubere Analyse vor Kauf
SQL-Lizenz pro Core, weil mehr Cores „nötig“ sind	15.000 € pro Core	MAXDOP, Query-Tuning
Mitarbeiterfluktuation wegen frustrierender Tools	schwer messbar, aber real	Antwortzeiten unter 2 Sekunden

 

Die Zahlen sind illustrativ und natürlich kundenabhängig. Aber selbst bei vorsichtiger Schätzung amortisiert sich eine Optimierungs-Beratung typischerweise im zweistelligen Tagesbereich — bevor die zweite Rechnung gestellt wäre.

Tiefer einsteigen — das Buch zum Thema

Wer das Thema systematisch lernen will, statt sich durch Blog-Posts zu hangeln: Ich schreibe gerade an einer fünfbändigen Reihe „SQL Server in der Praxis“. Band 1 widmet sich vollständig der Performance — von der ersten Messung bis zum nachhaltigen Betrieb. Ist bei Ulrich Boddenberg Publishing erschienen. Wer auf der Liste stehen möchte: einfach kurz Bescheid sagen.

Die SQL-Server-Reihe (in Arbeit) Band 1 — Performance: Messen, Tunen, Stabilisieren Band 2 — Security, Compliance und Governance Band 3 — Hochverfügbarkeit und Disaster Recovery Band 4 — Migration: von Altlasten zur modernen Plattform Band 5 — Für Entwickler: Was die Datenbank nicht verzeiht

 

Häufige Fragen zur SQL-Server-Optimierung

Wie schnell lässt sich SQL Server typischerweise optimieren?

Erste messbare Effekte zeigen sich häufig innerhalb von ein bis zwei Beratungstagen — typischerweise durch Konfigurations-Korrekturen und das Beheben fehlender Indizes. Eine vollständige Optimierung über alle fünf Stellschrauben dauert in mittelständischen Umgebungen erfahrungsgemäß zwischen fünf und zwölf Beratungstagen.

Brauche ich neue Hardware für bessere Performance?

In den meisten Fällen nicht. Eine saubere Konfiguration und gezielte Index-Optimierung holen aus bestehender Hardware oft mehr heraus, als ein Hardware-Upgrade bringen würde. Erst wenn die Software-Seite optimiert ist, lohnt eine Hardware-Investition — wenn überhaupt.

Welche SQL-Server-Versionen sind unterstützt?

Ich arbeite mit allen aktuellen und wartungsfähigen Versionen ab SQL Server 2016 — also SQL Server 2016, 2017, 2019 und 2022, sowohl On-Premises als auch Azure SQL Database und Azure SQL Managed Instance. Ältere Versionen behandle ich pragmatisch, empfehle aber immer eine Migration auf eine supportete Version.

Was unterscheidet eure Optimierung von einem reinen Hardware-Upgrade?

Hardware-Upgrades verschieben das Problem oft nur, sie lösen es selten. Ein falsch konfigurierter SQL Server bleibt auch auf doppelt so starker Hardware falsch konfiguriert — und kostet dann doppelt so viel Lizenz. Optimierung adressiert die Ursache, nicht das Symptom.

Können wir die Optimierung selbst durchführen?

Ja, das ist ausdrücklich vorgesehen. Mein Vorgehen umfasst Wissensaufbau im Team, dokumentierte Maßnahmen und nachvollziehbare Skripte. Ziel ist, dass die interne IT nach dem Projekt selbst weiß, was zu tun ist — und nicht, dass du für jeden weiteren Schritt wieder anrufen musst.

Welche Daten muss ich vor einer Optimierung bereitstellen?

Im Minimum: eine produktive SQL-Server-Instanz mit Lesezugriff für eine Analyse-Phase, Aufzeichnungen von Wait Stats und Top-Queries über einen repräsentativen Zeitraum, sowie eine Beschreibung der wichtigsten Geschäftsprozesse, die auf der Datenbank laufen. Den Rest sammle ich selbst.

Wir machen das zusammen

Schaut, was alles geht — und ruft mich an. Wer bis hierhin gelesen hat, ahnt, was möglich ist. Wer wissen will, was bei seinem System konkret geht, fängt am besten mit einer kurzen Bestandsaufnahme an. Ich biete dafür ein unverbindliches Erstgespräch von rund 45 Minuten — kein Sales-Pitch, sondern ein offener Austausch über Symptome, Datenmengen und realistische Erwartungen. Daraus wird entweder ein konkreter Optimierungs-Auftrag, eine Empfehlung an einen passenderen Anbieter, oder ein paar gute Tipps, mit denen das interne Team selbst weiterkommt. Alle drei Ausgänge sind in Ordnung. Boddenberg.de — Microsoft Enterprise Consulting aus Dortmund. Seit fast 30 Jahren im Geschäft. Mit Büchern, Tools und einer ziemlich klaren Haltung zur Frage: „Was geht da eigentlich?“ info@boddenberg.de | +49 231 22458 121