SQL Indizes Datenbankabfragen effizient optimieren

Wie der richtige Index die Performance deutlich verbessert

‍

Die Performance einer Anwendung ist ein wichtiger Faktor für eine gute Benutzererfahrung. Besonders bei Anwendungen mit vielen Benutzern und großen Datenmengen können langsame Datenbankabfragen schnell zu einem Problem werden. Während eine Abfrage mit wenigen Datensätzen oft nur wenige Millisekunden benötigt, kann dieselbe Abfrage bei mehreren Millionen Datensätzen deutlich langsamer werden.

Ein häufiger Grund für langsame Abfragen sind fehlende oder ungeeignete Datenbank-Indizes. Ohne einen passenden Index muss die Datenbank häufig alle Datensätze einer Tabelle durchsuchen, bevor das gewünschte Ergebnis gefunden wird. Dieser Vorgang kostet Zeit und belastet zusätzlich den Datenbankserver.

Viele Entwickler versuchen dieses Problem zu lösen, indem sie möglichst viele Indizes erstellen. Das kann einzelne SELECT-Abfragen zwar beschleunigen, führt aber nicht immer zu einer besseren Gesamtperformance. Jeder zusätzliche Index muss bei INSERT-, UPDATE- und DELETE-Operationen ebenfalls aktualisiert werden. Dadurch steigen sowohl der Speicherbedarf als auch der Aufwand für Änderungen an den Daten.

Deshalb stellt sich nicht die Frage, ob Indizes verwendet werden sollten, sondern wie sie sinnvoll eingesetzt werden können, um Datenbankabfragen effizient zu optimieren. Ein gut gewählter Index kann die Performance deutlich verbessern, während zu viele oder falsch gewählte Indizes den gegenteiligen Effekt haben können.

In diesem Artikel werden verschiedene Szenarien verglichen und anhand praktischer Beispiele gezeigt, welchen Einfluss SQL Indizes auf die Performance haben. Außerdem werden typische Fehler betrachtet und einige Empfehlungen für den täglichen Einsatz gegeben.

‍

Das Problem

Nehmen wir eine einfache Tabelle mit Kundendaten als Beispiel.

Customer
-----------------------------------------
Id , FirstName , LastName , Email , City , CreatedAt

‍

Ein Entwickler möchte einen Kunden anhand seiner E-Mail-Adresse suchen.

SELECT *
FROM Customer
WHERE Email = 'max@test.de';

‍

Der SQL-Befehl sieht einfach aus und funktioniert problemlos. Solange die Tabelle nur wenige Datensätze enthält, fällt auch keine Verzögerung auf.

Mit der Zeit wächst jedoch die Datenmenge. Aus einigen hundert Datensätzen werden zehntausende oder sogar Millionen Einträge. Genau an diesem Punkt beginnt die Datenbank, deutlich mehr Arbeit für dieselbe Abfrage zu leisten.

Existiert kein Index auf der Spalte Email, muss SQL Server jeden Datensatz überprüfen, bis die passende E-Mail-Adresse gefunden wurde. Dieser Vorgang wird als Table Scan bezeichnet. Je größer die Tabelle wird, desto länger dauert die Suche.

‍

Die folgende Abbildung zeigt vereinfacht den Unterschied:

Customer
---------------------------------------
1
2
3
4
...
999999
→ SQL Server durchsucht nahezu alle Datensätze

‍

Bei kleinen Tabellen spielt das oft keine Rolle. Bei großen Anwendungen kann dies jedoch schnell zu längeren Antwortzeiten führen. Besonders problematisch wird dies, wenn dieselbe Abfrage sehr häufig ausgeführt wird, beispielsweise bei Logins, Suchfunktionen oder API-Anfragen.

Bevor ein Index hinzugefügt wird, lohnt sich ein Blick darauf, wie Entity Framework dieselbe Abfrage erzeugt.

Abfragen mit Entity Framework

Die gleiche Abfrage kann auch mit Entity Framework Core geschrieben werden.

var customer = await context.Customers
    .FirstOrDefaultAsync(x => x.Email == email);

‍

Der LINQ-Code ist einfach und gut lesbar. Trotzdem entscheidet nicht Entity Framework über die Performance der Abfrage, sondern die Datenbank.

Existiert kein Index auf der Spalte Email, muss SQL Server weiterhin alle Datensätze durchsuchen. Entity Framework erzeugt zwar das passende SQL-Statement, die eigentliche Optimierung erfolgt jedoch in der Datenbank.

Das bedeutet, dass auch sauber geschriebener LINQ-Code langsam sein kann, wenn die Datenbank keine passende Indexstruktur besitzt.

‍

Einen Index hinzufügen

‍

In SQL Server kann ein Index beispielsweise so erstellt werden:

CREATE INDEX IX_Customer_Email
ON Customer(Email);

‍

Wird Entity Framework Core verwendet, kann der Index direkt im Datenmodell definiert werden.

builder.HasIndex(x => x.Email);

‍

Nach einer Migration wird der entsprechende Index automatisch in der Datenbank erstellt.

Der eigentliche LINQ-Code muss dabei nicht verändert werden.

var customer = await context.Customers
    .FirstOrDefaultAsync(x => x.Email == email);

‍

Genau das ist einer der größten Vorteile von Indizes. Die Anwendung bleibt unverändert, während die Datenbank dieselbe Abfrage deutlich effizienter ausführen kann.

‍

Vergleich

Der Unterschied zwischen beiden Varianten wird besonders bei großen Tabellen sichtbar.

‍

Angenommen, eine Tabelle enthält ungefähr eine Million Datensätze.

Die Suche nach einer E-Mail-Adresse kann beispielsweise folgende Laufzeiten besitzen:

‍

Die genauen Werte hängen selbstverständlich von der Hardware, der Datenmenge und der Datenbankkonfiguration ab. Das Beispiel zeigt jedoch deutlich, welchen Einfluss ein passender Index auf die Performance haben kann.

‍

Mehr Indizes bedeuten nicht automatisch mehr Performance

Nachdem Entwickler den positiven Effekt eines Indexes gesehen haben, entsteht häufig die Idee, möglichst viele Spalten zu indizieren.

Zum Beispiel:

Email, FirstName, LastName, City, PhoneNumber, Country, CreatedAt, Birthday, Status, CustomerNumber

‍

Auf den ersten Blick scheint dies sinnvoll zu sein. Schließlich könnten dadurch weitere Abfragen beschleunigt werden.

In der Praxis entstehen jedoch neue Probleme.

Jeder Index muss bei jeder Änderung der Daten ebenfalls aktualisiert werden.

Das betrifft insbesondere folgende Operationen:

• INSERT
• UPDATE
• DELETE

‍

Dadurch benötigt die Datenbank mehr Zeit für Schreiboperationen. Zusätzlich steigt der Speicherverbrauch und die Wartung der Datenbank wird aufwendiger.

Vor allem Tabellen mit vielen Änderungen können dadurch trotz schneller SELECT-Abfragen insgesamt langsamer werden.

Deshalb gilt: Ein Index sollte nicht erstellt werden, weil eine Spalte existiert, sondern weil sie regelmäßig in Abfragen verwendet wird.

‍

Best Practices

Indizes sollten immer auf Basis des tatsächlichen Nutzungsverhaltens erstellt werden. Bevor ein neuer Index hinzugefügt wird, lohnt es sich, die vorhandenen Abfragen zu analysieren und zu prüfen, welche Spalten regelmäßig verwendet werden.

Besonders sinnvoll sind Indizes auf Spalten, die häufig in folgenden Bereichen vorkommen:

• WHERE-Bedingungen
• JOIN-Abfragen
• ORDER BY
• GROUP BY

‍

Ein weiterer wichtiger Punkt ist die Selektivität einer Spalte. Je unterschiedlicher die gespeicherten Werte sind, desto sinnvoller ist häufig ein Index.

Ein gutes Beispiel ist eine E-Mail-Adresse. Da jede E-Mail in der Regel eindeutig ist, kann SQL Server den gesuchten Datensatz sehr schnell finden.

Anders sieht es bei einer Spalte wie Gender oder IsActive aus. Diese enthalten oft nur wenige unterschiedliche Werte. Ein Index bringt hier häufig nur einen geringen Vorteil oder wird von SQL Server sogar gar nicht verwendet.

‍

Zusammengesetzte Indizes

‍

Nicht jede Abfrage filtert nur nach einer einzigen Spalte.

Ein häufiges Beispiel ist eine Suche nach Stadt und Nachname.

SELECT *
FROM Customer
WHERE City = 'Berlin'
AND LastName = 'Müller';

‍

In solchen Fällen kann ein zusammengesetzter Index sinnvoll sein.

CREATE INDEX IX_Customer_City_LastName
ON Customer (City, LastName);

‍

Auch Entity Framework Core unterstützt zusammengesetzte Indizes.

builder.HasIndex(x => new
{
    x.City,
    x.LastName
});

‍

Dadurch kann SQL Server beide Suchkriterien gleichzeitig verwenden und die Abfrage weiter optimieren.

‍

Indizes regelmäßig überprüfen

‍

Mit der Zeit verändern sich Anwendungen.

Neue Funktionen entstehen, bestehende Abfragen werden angepasst und manche Bereiche werden kaum noch genutzt.

Deshalb sollten auch vorhandene Indizes regelmäßig überprüft werden.

Ein Index, der heute häufig verwendet wird, kann in einigen Monaten vollkommen überflüssig sein.

Ebenso kann eine neue Funktion einen zusätzlichen Index erforderlich machen.

Eine regelmäßige Analyse der Execution Plans oder der Datenbankstatistiken hilft dabei, unnötige Indizes zu erkennen und fehlende Indizes gezielt hinzuzufügen.

‍

Typische Fehler

Im Alltag treten häufig dieselben Fehler auf.

Zu viele Indizes

Viele Indizes verbessern zwar einzelne SELECT-Abfragen, verschlechtern aber Schreiboperationen und erhöhen den Speicherbedarf.

Index auf der falschen Spalte

Ein Index bringt nur dann einen Vorteil, wenn die Spalte tatsächlich häufig gesucht oder sortiert wird.

Keine Analyse der Abfragen

Ein Index sollte immer auf realen Abfragen basieren und nicht aus Vermutung erstellt werden.

Execution Plans ignorieren

SQL Server zeigt sehr genau, wie eine Abfrage ausgeführt wird. Wer Execution Plans regelmäßig analysiert, erkennt Performanceprobleme deutlich schneller.

‍

Fazit

Indizes gehören zu den wichtigsten Werkzeugen für die Optimierung von Datenbankabfragen. Bereits ein einzelner, gut gewählter Index kann die Ausführungszeit einer Abfrage deutlich reduzieren und die Belastung der Datenbank senken.

Gleichzeitig gilt jedoch, dass mehr Indizes nicht automatisch eine bessere Performance bedeuten. Jeder zusätzliche Index verursacht Aufwand bei Schreiboperationen und benötigt zusätzlichen Speicherplatz.

Deshalb sollten Indizes immer auf Basis der tatsächlichen Nutzung erstellt werden. Eine Analyse der häufig verwendeten Abfragen sowie der Execution Plans hilft dabei, sinnvolle Entscheidungen zu treffen und die Datenbank langfristig performant zu halten.

Wer Indizes gezielt und bewusst einsetzt, verbessert nicht nur einzelne Abfragen, sondern trägt dazu bei, dass die gesamte Anwendung auch bei wachsenden Datenmengen zuverlässig und effizient arbeitet.

‍