SQL Server Performance Tuning 2022: Was heute noch gilt – und was du besser lässt

Wenn ich bei Kunden zum ersten Mal einen SQL Server unter die Lupe nehme, entdecke ich oft dasselbe Bild: Standardkonfigurationen, veraltete Empfehlungen und falsch verstandene „Best Practices“, die aus früheren Zeiten übernommen wurden – ungeprüft. Dabei hat sich das Umfeld für SQL Server längst verändert: leistungsfähigere Hardware, virtualisierte Infrastrukturen, neue Features, und nicht zuletzt ein deutlich gestiegener Anspruch an Stabilität und Performance.

Ein Klassiker unter den Tuning-Empfehlungen ist ein Blogbeitrag von Brent Ozar aus dem Jahr 2011. Er beleuchtet drei zentrale Punkte der SQL Server-Konfiguration:
Lock Pages in Memory, Max Degree of Parallelism (MAXDOP) und Cost Threshold for Parallelism.

Ich habe diese Empfehlungen auf ihre Aktualität geprüft – mit Blick auf SQL Server 2022 (und einem Auge auf SQL Server 2025). In diesem Beitrag fasse ich zusammen, was aus heutiger Sicht noch sinnvoll ist – und worauf du lieber verzichten solltest.

---

Lock Pages in Memory – sinnvoll oder überholt?

Das Recht „Lock Pages in Memory“ (LPIM) wurde früher häufig als Allheilmittel empfohlen, um zu verhindern, dass Windows unter Speicherdruck SQL Server-Speicher auf die langsame Auslagerungsdatei verschiebt. Die Idee dahinter ist nachvollziehbar – aber in der Praxis nicht immer hilfreich.

Heute gilt: In dedizierten SQL Server-Installationen, bei denen der Speicher sauber begrenzt wurde, kann LPIM als Schutzmechanismus durchaus Sinn ergeben. In geteilten oder virtualisierten Umgebungen kann es dagegen mehr schaden als nutzen.

Mein Fazit: LPIM ist kein genereller Performance-Booster, sondern ein gezieltes Schutzinstrument – und sollte nur dann aktiviert werden, wenn die Umgebung dafür geeignet ist. Auf Standardkonfigurationen hat es in der Regel keinen Platz.

---

MAXDOP – die Kontrolle zurückholen

Viele SQL Server laufen mit dem Default MAXDOP = 0, was bedeutet: SQL Server nutzt alle verfügbaren Kerne, wenn eine Abfrage parallelisiert wird. Was zunächst effizient klingt, entpuppt sich im Alltag oft als Performancebremse – gerade bei OLTP-Workloads.

In modernen Umgebungen empfiehlt es sich, die Parallelität klar zu begrenzen – abhängig von der Architektur des Servers und der tatsächlichen Nutzung. Die allgemeine Tendenz geht heute klar zu Werten zwischen 4 und 8 – deutlich unterhalb der theoretisch verfügbaren Kerne.

Meine Empfehlung: MAXDOP gehört zu den Parametern, die ich nie auf dem Standardwert belasse. Eine angepasste Einstellung bringt meist sofort spürbare Verbesserungen – nicht nur bei großen Abfragen, sondern auch im gesamten Workload-Verhalten.

---

Cost Threshold for Parallelism – raus aus den 1990ern

Der „Cost Threshold for Parallelism“ legt fest, ab welchem Aufwand der SQL Server überhaupt eine Abfrage parallelisiert. Der Standardwert liegt bis heute bei 5 – ein historischer Wert, der auf heutiger Hardware völlig überholt ist.

Dieser niedrige Schwellenwert führt dazu, dass selbst kleine Abfragen unnötig parallelisiert werden – mit entsprechendem Overhead bei der Thread-Verwaltung. Die Folge: CPU-Last, THREADPOOL-Waits, instabiles Laufzeitverhalten.

Mein Fazit: Ein höherer Wert – etwa 25 bis 50 – bietet in vielen Umgebungen mehr Stabilität und spart Ressourcen. Welche Zahl im Einzelfall passt, hängt vom Workload ab – aber eins ist sicher: 5 ist heute kein sinnvoller Ausgangspunkt mehr.

---

Weitere wichtige Performance-Stellschrauben

Neben den drei genannten Parametern gibt es eine ganze Reihe weiterer Einstellungen, die bei der Inbetriebnahme oder Überprüfung eines SQL Servers relevant sind. Diese betreffen zum Beispiel:

• die Speicherbegrenzung für den SQL Server
• die Konfiguration der TempDB
• Backup-Strategien und Komprimierung
• die Initialisierung von Datenbankdateien
• Optionen zur Notfalladministration und Diagnose
• oder das Verhalten bei Statistikaktualisierungen und Ad-hoc-Queries

Welche dieser Punkte in welcher Form sinnvoll sind, hängt stark von der Umgebung ab – und genau hier beginnt in meiner Arbeit das individuelle Tuning. Es gibt keine „One Size Fits All“-Konfiguration. Wohl aber Prinzipien, die ich in jedem Projekt anwende: Verstehen, bewerten, optimieren – auf Basis echter Nutzung und nicht auf Verdacht.

---

Fazit: SQL Server Performance Tuning 2022 – kein Hexenwerk, aber auch nichts für Copy & Paste

Die Empfehlungen aus Brent Ozars Beitrag von 2011 haben im Kern bis heute Bestand – doch moderne SQL Server-Installationen verlangen präzisere Entscheidungen. Viele Defaults sind nicht mehr zeitgemäß. Und die Auswirkungen einzelner Parameter sind heute komplexer als früher.

Mein Rat: Wer mit SQL Server arbeitet – sei es als Administrator, als Entwickler oder als Entscheider – sollte sich mit den Grundprinzipien des Performance Tunings vertraut machen. Nicht alles muss sofort angepasst werden, aber wer gar nicht hinsieht, verschenkt Stabilität, Geschwindigkeit und im Zweifel bares Geld.

Wenn du dir nicht sicher bist, ob dein SQL Server optimal läuft: Lass uns gemeinsam hinschauen.