SQL-Labor: Messdaten & Versuchsaufbau

Warum 10 Millionen synthetische Zeilen?

In Kundenprojekten gilt strikte berufliche Diskretion: Echtdaten von Kunden verlassen niemals das Kundensystem. Um Kunden und Entwicklerteams trotzdem den empirischen Beweis zu liefern, habe ich eine typische Unternehmens-Bewegungstabelle (Bestellungen / Buchungen) synthetisch generiert.

10 Millionen Datensätze zwingen die SQL-Engine dazu, reale physische I/O-Pfade zu beschreiten. Der Clustered Index belegt rund 350.000 Datenseiten (ca. 2,8 GB). Hier lässt sich exakt nachweisen, wie der Query Optimizer arbeitet, wenn die Datenmenge das CPU-Cache-Limit übersteigt.

Die Testtabelle und das Schema

Die Struktur bildet ein klassisches operatives Geschäftsmodell ab:

CREATE TABLE dbo.KundenBewegung (
    Id             bigint IDENTITY(1,1) NOT NULL,
    Nachname       varchar(50)  NOT NULL,
    Vorname        varchar(50)  NOT NULL,
    Stadt          varchar(50)  NOT NULL,
    GeschaeftsJahr smallint     NOT NULL,
    Umsatz         decimal(12,2) NOT NULL,
    Bemerkung      varchar(200) NULL,
    CONSTRAINT PK_KundenBewegung PRIMARY KEY CLUSTERED (Id)
);

Die Verteilung: Häufige Nachnamen (z. B. „Müller“ ca. 270.000 Treffer), realistische Städte-Kardinalität und Geschäftsjahre von 2018 bis 2026.

Der „Tipping Point“: Warum Stufe 1 ignoriert wird

In Stufe 1 legen wir einen Index auf nur eine Spalte an: CREATE INDEX IX_Nachname ON KundenBewegung(Nachname). Viele Entwickler erwarten, dass die Abfrage nun schnell wird. Doch SQL Server ignoriert den Index komplett und macht weiterhin einen vollen Table Scan!

Die mathematische Ursache: Der Name „Müller“ liefert 271.384 Zeilen. Ein Seek auf IX_Nachname fände zwar schnell die Treffer, müsste dann aber 271.384 Mal einzeln per wahlfreiem I/O in den Clustered Index springen, um Vorname, Stadt und Umsatz nachzulesen. Da die gesamte Tabelle nur 350.000 Seiten hat, errechnet der Optimizer: 271.000 wahlfreie Einzelsprünge kosten mehr Zeit als die 350.000 Seiten einfach sequenziell komplett durchzulesen. Das ist der Tipping Point.

Warum „Logical Reads“ die ehrlichste Messzahl sind

Laufzeiten in Millisekunden schwanken: Sie hängen von CPU-Takt, Thermal Throttling, Virtualisierung und Hintergrundaktivitäten des Betriebssystems ab.

Die einzig verlässliche, deterministische Größe in SQL Server sind die Logical Reads (logische Lesevorgänge von 8-KB-Seiten). Ob ein System 350.000 Seiten aus dem RAM oder von einer NVMe liest: Die Arbeit der CPU, die Anzahl der Speicherzugriffe und das Verdrängen anderer Daten aus dem Buffer Cache sind identisch. Ein Tuning, das die Reads von 350.000 auf 11 senkt, war im Labor um Größenordnungen schneller. Weniger Lesevorgänge bedeuten auf jedem System weniger Arbeit; der genaue Faktor hängt von der Hardware ab.

Collation & Implizite Typkonvertierung

Wenn .NET / Entity Framework einen Parameter als Unicode (nvarchar) schickt, die Spalte in der Datenbank jedoch varchar ist:

Die Ursache: Gemäß SQL Server Data Type Precedence hat nvarchar einen höheren Vorrang als varchar. SQL Server muss daher nicht den Parameter umwandeln, sondern jede einzelne Tabellenzeile per interner Funktion konvertieren (Plan-Warnung: CONVERT_IMPLICIT). Ein Seek ist unmöglich; die CPU brennt 2,4 Sekunden lang.

Mengenübergabe (IN-Listen) & Plan-Cache-Bloat

Wie übergibt man 2.000 IDs aus C# an die Datenbank? Der Vergleich von dynamischen Strings vs. Table-Valued Parameters (TVP):

Die Ursache: Dynamisch zusammengebaute IN (1, 2, 3...)-Strings fluten den Plan-Cache mit Einmal-Plänen. Bei 50.000 Aufrufen belegte die Ad-hoc-Variante 781 MB Arbeitsspeicher im Plan-Cache, während die parametrisierte TVP-Lösung mit 0,1 MB auskam.

Text-Schlüssel vs. Technischer int-Key (Surrogate)

Ein natürlicher 3-teiliger Textschlüssel (56 Zeichen) gegenüber einem schlanken int-Surrogate-Key:

Die Ursache: Der Text-Primärschlüssel wiederholt sich in jedem Fremdschlüssel und in jedem Nonclustered Index der Kindtabellen. Tabellen und Indizes werden 4,4-mal größer und belasten den Buffer Pool dauerhaft.

SARGability: Führender Platzhalter (LIKE '%berg')

Endungssuche auf Firmennamen. Standard-Scan vs. berechnete Spalte mit REVERSE():

Die Ursache: LIKE '%berg' kann keinen B-Tree nutzen. Mit einer berechneten Spalte FirmaRev AS REVERSE(Firma) und einem Index darauf wird aus der Endungssuche eine blitzschnelle Präfixsuche LIKE 'greb%': ×617 schneller.

Datenbankgrenzen: Collation-Falle

Abfragen über Datenbankgrenzen hinweg:

Die Ursache: Weicht die Sortierung der Remote-Datenbank ab, muss SQL Server alle Daten lokal ziehen und Zeile für Zeile vergleichen. Index-Seeks auf der Gegenseite werden unmöglich.

Normalisierung (3NF) & Datenqualität

Klartext-Spalten in der Haupttabelle vs. normalisierte Nachschlagetabelle (z. B. StadtId):

Die Ursache: Eine Suche auf einer kleinen Nachschlagetabelle (5.000 Städte) kostet fast nichts, bevor über die kompakte int-Spalte gejoint wird – 46,4-mal schneller, und das Modell verhindert abweichende Schreibweisen derselben Stadt.

Prozedur gegen View: wo gefiltert wird

Gesucht ist der Umsatz der 100 Kunden einer Stadt, mit passenden Indizes. Die Logik steckt einmal in einer View, einmal in einer Prozedur ohne Parameter, deren Ergebnis erst außen gefiltert wird (INSERT … EXEC):

Die Ursache: Die View wird in die Abfrage eingesetzt, der Filter auf die Stadt wandert nach innen und nutzt den Index. Die Prozedur berechnet dagegen alle 10 Mio. Kunden, erst danach wird gefiltert. Das liegt nicht an der Prozedur an sich: Mit Parameter braucht sie 54 ms, so viel wie die View. Gemessen sind Client-Zeiten bei kaltem Cache.

Einen Monat entfernen: DELETE gegen Partition leeren

Dieselben Buchungen über 120 Monate, einmal nach Buchungsnummer gespeichert, einmal nach Datum, einmal nach Monat partitioniert. Entfernt wird ein Monat (833.333 Zeilen):

Die Ursache: DELETE schreibt jede Zeile ins Protokoll und pflegt jeden Index mit. Das Leeren einer Partition gibt nur deren Seiten frei. Voraussetzung: Der Monat liegt genau in einer Partition, und alle Indizes sind gleich partitioniert. Gemessen wurde nur die Löschanweisung, in einer Transaktion, die danach zurückgerollt wurde.

Partitionierung macht Abfragen nicht automatisch schneller

Dieselben drei Tabellen wie in Messreihe 8, diesmal zwei Abfragen: die Summe eines Monats und die Summe eines Kontos über alle Jahre:

Die Ursache: Für die Monatssumme genügt ein Index nach Datum; die Partitionierung war in dieser Messung sogar etwas langsamer. Die Kontoabfrage kennt den Monat nicht und muss in allen 120 Partitionen suchen. Partitionierung ist ein Werkzeug für die Datenpflege (Messreihe 8), kein Ersatz für den passenden Index.

Join über drei Tabellen bei 100 Millionen Kunden

Kunde, Bestellung und Position; gesucht sind die 400 Positionen der Kunden einer Stadt. Ohne Index auf den Fremdschlüsseln gegen Indizes auf Stadt und Fremdschlüsseln (mit INCLUDE):

Die Ursache: Ohne Index muss SQL Server alle 400 Mio. Positionen lesen, um 400 zu finden – 2.177-mal so viele Seiten. Drei Unterabfragen je Kunde statt des Joins: 50.737 ms gegen 232 ms (Faktor ×219). Erzwungene Nested Loops ohne Index wurden bei dieser Größe nicht gemessen.