Seit mehr als 30 Jahren arbeite ich mit relationalen Datenbanken – von Nachtläufen im Mittelstand bis zu Datenbanken im Milliarden- und Terabyte-Bereich in der Halbleiterproduktion bei NXP. Auf dieser Seite stehen Vorgehen, Praxisfälle und Messungen aus meinem SQL-Labor, jeweils mit Weg zu den Rohdaten.
Datenbankentwicklung, Performance-Tuning und Datenmodellierung in Konzern-IT, Produktion, FDA-regulierten Medizinstudien und Mittelstand – Schwerpunkt MS SQL Server (T-SQL, SSIS, SSRS) sowie Oracle (PL/SQL), MySQL, PostgreSQL und Redis.
Bei NXP Semiconductors wurden monatlich rund 1,4 Mrd. neue Seriennummern in Echtzeit gegen 64 Mrd. Bestandszeilen (4 TB) auf Duplikate geprüft – über Insert-only-Tabellen, entkoppelte Redis-Queues, verteilte Satelliten-Datenbanken und unterbrechungsfreie Batch-Migration im laufenden 24/7-Betrieb.
Statt Bauchgefühl nutze ich ein automatisiertes Messlabor für Ausführungspläne, Logical Reads, Plan-Cache und Sperren – Index-Matrix und zehn weitere Labor-Messreihen ansehen.
Die Beispiele sind anonymisiert (Kundendaten gebe ich grundsätzlich niemals weiter). Werte aus der Erinnerung sind als Größenordnung angegeben – die exakten Ursachen und Wirkungen habe ich im Laborabschnitt darunter an 10 Millionen Zeilen reproduzierbar nachgestellt und gemessen.
Ein Kunde in Österreich erlebte im laufenden Betrieb Blockierungen durch Transaktionen, die sich im Testsystem nie nachstellen ließen. Ursache war eine Stored Procedure, die ihre Abfrage je nach Fall per String-Verkettung zusammensetzte und dynamisch ausführte.
Ich habe sie in einen Verteiler (Delegator) und zwei Prozeduren mit festem, parametrisiertem T-SQL aufgeteilt. Damit prüft SQL Server die Abfragen vorab und nutzt für jeden Zweig einen stabilen Ausführungsplan im Plan-Cache. Bis zum Ende meines Einsatzes trat der Fehler nicht wieder auf.
Ein Entwickler hatte mehrere Tage versucht, eine langsame Abfrage im C#-Code zu beschleunigen. Die Ursache lag in der Datenbank: Durch einen fehlenden abdeckenden Index musste SQL Server Millionen Zeilen per Scan und Key Lookup lesen.
Nach Anlage des passenden Index lief die Abfrage rund hundertmal schneller (Größenordnung aus der Erinnerung), ohne eine einzige Zeile Programmcode in der Anwendung zu ändern.
Nächtliche Reports und ETL-Strecken, die morgens nicht fertig sind, bleiben selten allein: Wer lange läuft, hält Exklusiv- und Seitensperren (`LCK_M_*`) und bremst die Prozesse neben sich – die wiederum andere blockieren.
Solche Nachtläufe habe ich regelmäßig von mehreren Stunden auf gut eine Stunde gebracht, indem ich zu große Transaktionen aufgelöst, Schleifen durch mengenorientiertes SQL ersetzt und die wenigen Engpässe im Ausführungsplan beseitigt habe.
Ein Kunde speicherte in seiner NoSQL-Datenbank Session-Variablen, die mehrere Sessions gemeinsam nutzten. Die Anwendung war massiv zu langsam und es war extrem eilig. Eine Testumgebung mit den Kundenkonfigurationen war kurzfristig nicht herstellbar, Logs oder Messdaten existierten nicht.
Ich habe den Quelltext Zeile für Zeile durchdacht und den Engpass identifiziert: Eine Tabelle, die festhielt, welche Session welche Variablen nutzte, wurde bei jedem Zugriff mehrfach durchsucht – pro Durchlauf ein bis zwei Sekunden Verzögerung.
Die Lösung war ein NoSQL-Muster statt relationaler Suche: Die Session erhält unter ihrer bekannten ID direkt die Referenzen auf ihre Variablen. Das Kunden-Team hat das Prinzip sofort verstanden und selbst umgesetzt: Reaktionszeit unter wenigen Millisekunden – kein spürbarer Zeitaufwand mehr.
Dieselbe Suchabfrage (`WHERE Nachname = … AND Stadt = … AND GeschaeftsJahr >= …`) auf einer Tabelle mit 1 und 10 Millionen Zeilen, jeweils mit einer besseren Indexstufe. Die Messung läuft vollautomatisch per PowerShell- und T-SQL-Skript und ist jederzeit reproduzierbar.
Clustered Index Scan: Liest alle 350.000 Datenseiten komplett durch. Höchste I/O- und CPU-Belastung auf Anschlag.
Tipping Point: Der Optimizer ignoriert den Index, weil Key Lookups bei 271.000 Treffern teurer wären als ein Scan.
2× Seek + Merge Join + Key Lookup: Schneller, aber tausende Seitensprünge (Key Lookups) belasten I/O und Cache.
Index Seek + Key Lookup: Suchspalten optimal gereiht, aber fehlende Ausgabespalten erzwingen noch 2.692 Lookups.
Reiner Index Seek (INCLUDE): Alle benötigten Daten liegen direkt im B-Tree. Kein einziger Zugriff auf die Basistabelle nötig.
Ein fehlender Index ist nur der Anfang. Für meine Beratungs- und Optimierungspraxis habe ich ein eigenes Test-Framework aufgebaut, das typische Architekturentscheidungen an 1 bis 100 Millionen Zeilen inklusive Showplan-XML, CPU-Zeit und Memory Clerks vermisst.
Wenn .NET/EF einen Unicode-Parameter (@p nvarchar) an eine varchar-Spalte übergibt, zwingt die Typ-Rangfolge unter Standard-SQL-Collation zu einem Zeilen-Scan:
Unter SQL-Sortierung muss SQL Server jede einzelne Zeile umwandeln (Plan-Warnung: CONVERT_IMPLICIT, 3.011 ms CPU-Zeit). Aus 3 Seitengriffen wird ein massiver Scan. Labor-Messdaten & Sortierungs-Matrix ansehen →
Wie übergibt man hunderte oder tausende IDs aus C# an SQL Server? Vier Verfahren bei 10 bis 2.000 IDs und bei 50.000 Einzelaufrufen gegeneinander gemessen:
Einzelparameter blähen den Plan-Cache auf; 50.000 Ad-hoc-Abfragen belegen 781 MB Speicher gegen 0,1 MB bei parametrisierten Aufrufen. Table-Valued Parameters (TVP) liefern einen stabilen Plan ohne Kompilierlast. Labor-Messdaten & 4-Methoden-Vergleich ansehen →
Ein dreiteiliger Fachschlüssel (Mandant + Bereich + Artikelnummer, ca. 56 Bytes) wiederholt sich in jeder Kindtabelle und jedem Index:
Der Textschlüssel macht Tabellen und Indizes 4,4-mal so groß und den Verbund über alle Kinder 2,5-mal so langsam (1.142 ms vs. 471 ms). Der Fachschlüssel bleibt als UNIQUE-Constraint auf der Elterntabelle erhalten. Labor-Messdaten & Metadaten-Skript ansehen →
LIKE '%berg')Eine Endungssuche wie WHERE Firma LIKE '%berg' ist nicht sargable – selbst mit Index auf Firma liest SQL Server alle 49.001 Indexseiten:
Mit einer berechneten Spalte FirmaRev AS REVERSE(Firma) und Index wird aus der Endungssuche ein gezielter Präfix-Seek. Das senkt die Lesevorgänge um den Faktor ×1.140 und die Laufzeit von 4 Sekunden auf 6,3 Millisekunden. Labor-Messdaten & Berechnete Spalte ansehen →
Abfragen über Instanz- und Datenbankgrenzen kippen je nach Syntax und Sortierung in völlig unterschiedliche Ausführungspläne:
Bei großen Verbünden zwingt OPENQUERY in zeilenweise Nested Loops. Weicht zudem die Collation der Zieldatenbank ab, verhindert die implizite Konvertierung den Index Seek (Faktor ×119 I/O). Labor-Messdaten & Remote-Vergleich ansehen →
Stehen Attribute wie Stadt und Zahlungsart als Klartext in der Bewegungstabelle statt als schlanker int-Fremdschlüssel:
Auf der kleinen Nachschlagetabelle kostet die Mustersuche fast nichts, bevor über die kompakte StadtId gejoint wird – 46,4-mal schneller. Auch die Widerspruchsprüfung sinkt von 21.584 auf 32 Reads. Labor-Messdaten & Modellierungsvergleich ansehen →
Im gemessenen Fall (synthetische Daten, kalter Cache) dieselbe Frage – Umsatz der Kunden einer Stadt – einmal über eine View, einmal über eine Prozedur ohne Parameter, deren Ergebnis erst außen gefiltert wird:
Die View lässt den Filter bis an den Index durch; die Prozedur rechnet alle 10 Mio. Kunden durch. Eine Mehranweisungs-Funktion liegt mit 53.095 ms dazwischen. Mit Parameter ist die Prozedur so schnell wie die View (54 ms). Labor-Messdaten ansehen →
Ein Monat (833.333 Zeilen) wird aus 100 Mio. Buchungen entfernt – per DELETE oder durch Leeren der Monatspartition:
DELETE protokolliert jede Zeile und pflegt jeden Index; das Leeren einer Partition gibt nur deren Seiten frei. Voraussetzung: Der Monat liegt genau in einer Partition, alle Indizes sind gleich partitioniert. Labor-Messdaten ansehen →
Dieselben Buchungen, einmal mit einfachem Index nach Datum, einmal nach Monat partitioniert:
Die Kontoabfrage kennt den Monat nicht und sucht in allen 120 Partitionen. Auch die Monatssumme war partitioniert nicht schneller: 244 ms gegen 173 ms mit einfachem Datumsindex. Partitionierung dient der Datenpflege; für Abfragen ersetzt sie den passenden Index nicht. Labor-Messdaten ansehen →
Gesucht sind die 400 Positionen der Kunden einer Stadt – ohne und mit Indizes auf Stadt und Fremdschlüsseln:
Mit drei Unterabfragen je Kunde statt des Joins: 50.737 ms gegen 232 ms (×219). Labor-Messdaten ansehen →
In gewachsenen Datenbanken wiederholen sich die Muster. Diese sechs Ursachen begegnen mir am häufigsten.
Ein Index pro Spalte hilft wenig. Entscheidend sind Spaltenreihenfolge (Gleichheit vor Bereich), abdeckende Spalten (INCLUDE gegen teure Key Lookups) und gefilterte Indexe – samt Beachtung von Parameter Sniffing und OPTION (RECOMPILE).
Passen Datentyp oder Collation von Spalte und Parameter nicht zusammen (z. B. varchar-Spalte gegen nvarchar aus Entity Framework), wandelt SQL Server jede Zeile beim Lesen um – und fällt vom Index Seek auf einen kompletten Scan zurück.
Als Text verkettete Abfragen fluten den Plan-Cache mit Einmal-Plänen, kosten bei jedem Aufruf CPU-Kompilierzeit und verhindern stabile Ausführungspläne. Parametrisierte Aufrufe und Table-Valued Parameters (TVP) beseitigen Plan-Cache-Flut und Kompilierlast; gegen Parameter Sniffing helfen gezielt OPTION (RECOMPILE) oder getrennte Pläne.
Bedingungen wie LIKE '%berg' oder Funktionen auf Indexspalten (YEAR(Datum) = …, ISNULL(Spalte, …)) machen vorhandene Indexe blind. Umgestellte Prädikate oder indizierte berechnete Spalten stellen den Index Seek wieder her.
Zusammengesetzte Text-Primärschlüssel vervielfachen sich in jedem Fremdschlüssel und jedem Nonclustered Index der Kindtabellen. Technische Schlüssel (int/bigint) halbieren oft den RAM-Bedarf im Buffer Pool.
Große Transaktionen und Cursorschleifen halten Sperren und lösen Kettenblockaden aus – besonders in Nachtläufen. Mengenorientiertes SQL, kleinere Transaktionsschritte und passende Isolationsstufen lösen den Stau auf.
In gewachsenen Datenbanken hat jede Änderung Nebenwirkungen: Welche Prozedur, welche View, welcher SQL-Agent-Job oder welches SSIS-Paket bricht, wenn man eine Tabelle oder einen Schlüssel anfasst? Deshalb verlasse ich mich nicht auf Vermutungen, sondern auf deterministische Werkzeuge.
Meine Analyse-Skripte werten Systemkataloge (sys.dm_db_partition_stats, sys.dm_exec_query_stats, sys.index_columns, Showplan-XML) aus, ohne große Tabellen zu scannen. So lässt sich der Speichergewinn eines Schlüssel- oder Indexumbaus schon vor dem Eingriff aus den Katalogdaten berechnen.
Mit COMPIDDA habe ich ein eigenes Analyse-Toolset (über 4.000 automatisierte Tests) entwickelt, das bis zu 19 Quelltypen – T-SQL (Prozeduren, Views, Trigger, dynamisches SQL, OPENQUERY, Linked Server über ScriptDom), SSIS-Pakete, SQL-Jobs, SSRS-Berichte und C#/.NET-Zugriffe – einliest und als Abhängigkeitsgraph (R/W/X) mit exakter Fundstelle darstellt. Für komplette gewachsene oder verwaiste IT-Landschaften ist dies als eigenständiges, separat bepreistes Vor-Ort-Assessment mit Toolset-Einsatz buchbar (Details zum COMPIDDA-Assessment →).
Jede Maßnahme bekommt vorab ein messbares Erfolgskriterium – Laufzeit, Lesevorgänge, Wartezeit – und wird danach unter denselben Bedingungen nachgemessen; Ergebnismengen vergleiche ich per Prüfsumme mit dem Altstand. KI-Werkzeuge nutze ich als Beschleuniger für Skripte und Testfälle; ob dabei Code oder Metadaten aus Ihrem Haus verarbeitet werden dürfen, entscheiden Sie vorab. Geraten wird an Ihrer Datenbank nichts.
Wo keine ausreichenden Tests vorhanden sind, schreibe ich keinen Code im großen Stil um. Ich setze gezielt an den Stellen an, die am meisten bewirken – oft an Indexen, Statistiken und einzelnen Stored Procedures, ohne die Anwendung anzufassen. Wenn tiefere Umbauten nötig sind, sichern wir die abhängigen Pfade vorab mit automatisierten Tests und Prüfsummen ab.
Eine Indexoptimierung wirkt oft innerhalb von Stunden. Änderungen an der Programmierung brauchen Tage bis Monate. Neue Hardware kostet Beschaffungszeit, eine Auszeit des Servers und Geld – und bringt meist nur einen Bruchteil dessen, was ein passender Index erreicht (im Labor war bei 100 Mio. Zeilen ein auf 2 Kerne und 1.300 MB gedrosselter SQL Server mit Covering Index 14.864-mal so schnell wie ein 8-Kern-Server mit 13.000 MB ohne Index; Laborwert mit synthetischen Daten, Zeiten um 1 ms sind grob – schon bei 2 ms wären es rund 8.900-mal; Plattengeschwindigkeit und Speicherbandbreite sind nicht nachgebildet). Deshalb ist dies meine bevorzugte Prüfreihenfolge.
Warum Hardware-Tuning 2026 eine Kostenfalle ist (Vergleich ansehen) →
Wenn Datenbanken langsam werden, ist der Reflex vieler IT-Abteilungen: „Wir brauchen einen größeren Server, mehr RAM und schnellere Datenträger.“ Doch mehr Hardware bringt bei einer Abfrage ohne passenden Index nur einen begrenzten Faktor: Im Labor war bei 100 Mio. Zeilen der Server mit 8 Kernen und zehnfachem Speicher nur 1,7-mal so schnell wie der mit 2 Kernen – bei hohen Microsoft-Lizenzkosten und langer Vorlaufzeit. Ein passender Index machte die Abfrage im Labor bei 10 Mio. Zeilen dagegen ×358 schneller – Arbeit weniger Stunden.
Mehr CPU-Kerne und schnellere NVMe-Platten beschleunigen nur den Transport, ändern aber nicht die Ursache: Der Server muss weiterhin dieselbe gigantische Datenmenge durch den I/O-Pfad pumpen.
Der Index ändert nicht die Geschwindigkeit der Leitung, sondern wie viel transportiert werden muss: Die Abfrage liest punktgenau nur noch die exakten Treffer.
Microsoft lizenziert SQL Server pro Prozessorkern (2-Kern-Pack laut Microsoft-Preisliste SQL Server 2025: Standard 3.945 $, Enterprise 15.123 $, geschätzter Einzelhandelspreis). Wer von 8 auf 32 Kerne aufrüstet, um ineffiziente Abfragen per Rechenpower zu überdecken, zahlt allein für die SQL-Enterprise-Kerne rund 180.000 $ mehr – plus Windows-Server-Kernlizenzen und gegebenenfalls Lizenzen für weitere Knoten.
Weil der weltweite KI-Boom DRAM- und NAND-Kapazitäten in High-Bandwidth-Memory (HBM) saugt, prognostizierte TrendForce im Februar 2026 für Server-DRAM im 1. Quartal 2026 einen Preisanstieg von rund 90 % gegenüber dem Vorquartal (Quelle). Für Server-Bauteile wie BMC-Chips nannte TrendForce im April 2026 Lieferzeiten von 21 bis 26 Wochen (Quelle). Die alte Management-Annahme „Hardware kaufen geht schneller als Entwickler ransetzen“ wird 2026 durch Preise und Lieferzeiten bei einzelnen Bauteilen erschwert.
Berechnete Anzeigetexte (z. B. Zusammenfügen von Anrede, Vorname, Nachname oder Stringoperationen) gehören in die C#/.NET-Anwendung, nicht in den SQL Server. SQL Server ist der teuerste und am schwersten skalierbare Knoten. Textformatierungen in Views verbrauchen teure Kern-Zyklen und können Parallelität und Index-Seeks ausbremsen.
Eine seriöse Datenbankberatung verkauft keine Patentrezepte. Es gibt Szenarien, in denen Hardware-Investitionen tatsächlich alternativlos sind:
Die 4-Stufen-Reihenfolge für Entscheider: 1. Messen, wo die Wartezeit entsteht (I/O, CPU, Sperren oder Netzwerk). 2. Indexe prüfen und optimieren (Wirkung in Stunden, keine Kernlizenzkosten). 3. Abfragen und Anwendungscode anpassen (Tage bis Wochen). 4. Hardware erst als letzten Schritt – wenn die Messung eindeutig belegt, dass physikalische I/O- oder Speichergrenzen der echte Engpass sind.
Tausende Zeilen T-SQL, historische Verschachtelungen, Cursors statt Mengenoperationen – und die Entwickler von damals sind längst nicht mehr im Unternehmen. Niemand im Team traut sich an den Code ran, weil bei jedem Eingriff unvorhersehbare Folgefehler in der Produktion oder Monatsabrechnung drohen. Ich bringe Ruhe, Transparenz und Geschwindigkeit in gewachsene Prozedur-Landschaften.
Bei einem internationalen Spirituosenkonzern lief eine historisch gewachsene Landschaft aus rund 130 MSSQL-Stored-Procedures zur nächtlichen Datenkonsolidierung und Fehlerkorrektur: Tief verschachtelte Logik führte zu langen Laufzeiten und blockierte Folgesysteme.
Ich habe die gesamte Prozedurenlandschaft schrittweise analysiert, entwirrt und in weiten Teilen durch robuste, wartbare und signifikant performantere T-SQL-Lösungen abgelöst – im laufenden Betrieb, ohne Betriebsunterbrechung, abgesichert durch Prüfsummentests.
„Herr Hagen verfügt über eine außergewöhnlich tiefgehende technische Expertise in den Bereichen Datenbanken, Anwendungsarchitektur und Performance-Optimierung. Er arbeitet sehr strukturiert, analytisch und eigenverantwortlich und ist in der Lage, auch komplexe und historisch gewachsene Systemlandschaften schnell zu durchdringen und nachhaltig zu verbessern. Durch seine Tätigkeit konnten Transparenz, Wartbarkeit, Stabilität und Performance der eingesetzten IT-Systeme signifikant verbessert werden.“
— aus dem schriftlichen Referenzschreiben des Kunden
Bevor die erste Codezeile angefasst wird, liest mein Analyse-Werkzeug COMPIDDA den Codebestand aus, T-SQL über den offiziellen SQL-Syntaxbaum (ScriptDom). Sie sehen als interaktives Abhängigkeitsdiagramm: Welche Prozedur ruft wen auf? Wo greifen Views, Trigger, SQL-Jobs oder C#-Services zu? Was sich nicht eindeutig auflösen lässt, sehen Sie als markierten offenen Punkt. Für ganze IT-Landschaften ist dies auch als eigenständiges, separat bepreistes Vor-Ort-Assessment buchbar.
Gegen Regressionsfehler zeichnen wir vorab reale Eingabe- und Ausgabedaten auf – in Ihrer Umgebung und nach Ihrer Freigabe; die Aufzeichnungen verlassen Ihr Haus nicht. Für jeden aufgezeichneten Fall belegen NUnit-Testfälle und Prüfsummen (SHA-256) über die Ergebnismengen vor dem Deployment (auch direkt in Ihrer Azure-DevOps-Pipeline), dass die neue Prozedur exakt dieselben Daten liefert wie der Altcode.
Ich ersetze zeilenweise Cursors und WHILE-Schleifen durch mengengestützte Abfragen (Window Functions, CTEs), löse Deadlock-trächtige Transaktionsklammern auf und wandle ad-hoc verkettetes dynamisches SQL in feste, vorkompilierte Prozeduren mit stabilem Plan-Cache um.
Brennt bei Ihnen aktuell ein Nachtlauf oder blockiert eine 2.000-Zeilen-Prozedur das gesamte System? Schicken Sie mir Ihren Problemfall.
Oft werde ich gefragt, welche Kundenabfrage ich um welchen exakten Faktor beschleunigt habe. Messprotokolle, Schemas und Produktionsdaten aus Kundensystemen bleiben beim Kunden; ich nehme sie nicht mit und veröffentliche sie nicht. Werte aus früheren Projekten nenne ich deshalb nur als Größenordnung – und erfundene Zahlen nenne ich gar nicht.
Stattdessen habe ich typische Fälle im eigenen SQL-Labor nachgestellt: automatisiert, auf 1 bis 100 Millionen Zeilen synthetischer Testdaten, mit offengelegtem T-SQL, Ausführungsplänen und exakten Seitenzugriffen. Den Beweis an Ihrer eigenen Datenbank tritt der Performance-Check an.
Der Performance-Check ist mein Einstiegsangebot. Die Laborwerte auf dieser Seite sind eine Demonstration auf Testdaten; im Performance-Check sehen Sie die Wirkung an Ihrem eigenen System, bevor Sie über ein größeres Projekt entscheiden. Umfang und Aufwand stimmen wir im Erstgespräch ab und halten sie vorab schriftlich fest.
VIEW SERVER STATE); Tabelleninhalte sind nicht nötig.Sehen Sie sich vorab einen vollständigen Beispielbefund (PDF auf Basis von Labordaten) an: mit Management-Kurzfassung für Entscheider, technischen Vorher-Nachher-Messwerten, priorisierter Maßnahmenliste, Rückweg-Skripten und Kosten-Nutzen-Einordnung.
„… in der Lage, auch komplexe und historisch gewachsene Systemlandschaften schnell zu durchdringen und nachhaltig zu verbessern. Durch seine Tätigkeit konnten Transparenz, Wartbarkeit, Stabilität und Performance der eingesetzten IT-Systeme signifikant verbessert werden.“
Auszug aus der Referenz · internationaler Spirituosenkonzern
„Herr Hagen war in ganz besonders hohem Maße zuverlässig … zeigte vor allem aber auch immer wieder vollen Einsatz, wenn es darum ging, den operativen Betrieb sicherzustellen.“
Auszug aus dem Zeugnis · NXP Semiconductors
Weitere Referenzen auf der Startseite; vollständige Nachweise auf Anfrage.