SQL Server Indexierung für häufig geänderte Daten – Worauf du achten solltest

Wenn du mit einer Tabelle arbeitest, in die ständig Daten eingefügt, geändert oder gelöscht werden, dann kennst du das Problem: Performance-Verlust durch Index-Fragmentierung und ineffiziente Ausführungspläne. Ich sehe immer wieder, dass Indizes zwar vorhanden sind, aber nicht optimal genutzt werden. In diesem Beitrag zeige ich dir, worauf du achten solltest, um Indizes effizient für häufig geänderte Daten und deren Abfragen zu nutzen – und wie die richtige Reihenfolge der Spalten entscheidend sein kann. Daher erläutere ich in diesem Beitrag den Weg zu einer guten SQL Server Indexierung.

1. Index-Fragmentierung verstehen und vermeiden

Warum fragmentieren Indizes?

Häufige INSERTs, UPDATEs und DELETEs führen dazu, dass Indizes aufgebrochen und verstreut werden, im Alltags-Sprachgebrauch „fragmentiert“ werden. Dadurch können sich Abfragen verlangsamen, da der SQL Server einen suboptimalen Ausführungsplan erstellt, der dann mehr Speicherplatz und I/O benötigt, um die gewünschten Daten zu finden.

Checke deine Index-Fragmentierung:

SELECT 
    OBJECT_NAME(ips.object_id) AS TableName,
    i.name AS IndexName,
    ips.index_type_desc,
    ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE OBJECT_NAME(ips.object_id) = 'SalesOrderDetail';

Wenn die Fragmentierung hoch ist (z. B. über 30 %), solltest du die Indizes neu organisieren oder neu aufbauen:

ALTER INDEX ALL ON Sales.SalesOrderDetail REORGANIZE;  -- Bei Fragmentierung < 40 %
ALTER INDEX ALL ON Sales.SalesOrderDetail REBUILD;          -- Bei Fragmentierung > 40 %

Tipp: Falls du eine stark veränderliche Tabelle hast, solltest du überprüfen, ob ein HEAP (also eine Tabelle ohne Clustered Index) oder ein Clustered Index die bessere Wahl ist. Ein schlecht gewählter Clustered Index kann zu noch mehr Fragmentierung führen.

2. Index-Optimierung mit der richtigen Spaltenreihenfolge

Die Reihenfolge der Spalten in einem Index ist nicht egal. SQL Server liest von links nach rechts – das heißt, die erste Spalte im Index sollte die selektivste sein.

Vergleich: Falsche vs. richtige Reihenfolge

Suboptimaler Index:

CREATE NONCLUSTERED INDEX IX_SalesOrderID_ProductID
ON Sales.SalesOrderDetail (SalesOrderID, ProductID);

Optimierter Index:

CREATE NONCLUSTERED INDEX IX_ProductID_SalesOrderID
ON Sales.SalesOrderDetail (ProductID, SalesOrderID);

Warum ist das wichtig?

• Wenn die WHERE-Bedingung zuerst nach ProductID filtert, aber der Index mit SalesOrderID beginnt, kann SQL Server ihn nicht effizient nutzen.
• Der richtige Index (mit ProductID zuerst) ermöglicht einen Index Seek statt eines teuren Index Scan.
• Falls die Abfragen sowohl ProductID als auch SalesOrderID filtern, solltest du analysieren, welche Spalte selektiver ist. Eine Spalte mit mehr eindeutigen Werten sollte zuerst stehen.

Prüfe, ob dein Index effizient genutzt wird:

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT SalesOrderID, ProductID, OrderQty
FROM Sales.SalesOrderDetail
WHERE ProductID = 870
AND SalesOrderID > 50000;

Falls der SQL Server einen Index Scan anstelle eines Index Seek verwendet, könnte die Reihenfolge falsch sein, heißt weiter die Abfrage und Indexstruktur untersuchen und optimieren => weiter testen.

3. Covering Index für häufige Abfragen

Ein Covering Index speichert neben den Index-Spalten auch zusätzliche Spalten, um teure Lookups zu vermeiden. Perfekt für Tabellen mit vielen Lesezugriffen!

CREATE NONCLUSTERED INDEX IX_CoveringIndex
ON Sales.SalesOrderDetail (ProductID, SalesOrderID)
INCLUDE (OrderQty, LineTotal);

Vorteil: Schnellere Abfragen, weil alle benötigten Spalten direkt im Index stehen.

Wann lohnt sich das?

• Wenn eine Abfrage häufig ausgeführt wird und mehrere Spalten zurückliefert.
• Wenn du teure Key Lookups vermeiden möchtest, die unnötige I/O verursachen.
• Falls du SELECT * verwendest, ist ein Covering Index nicht sinnvoll – hier sollte stattdessen die Abfrage angepasst werden.

4. Index-Wartung und regelmäßige Optimierung

Die beste Index-Strategie nützt nichts, wenn du sie nicht regelmäßig überprüfst! Hier sind einige Best Practices:

Nutze master.sys.dm_db_index_usage_stats, um ungenutzte Indizes zu identifizieren:

SELECT * FROM sys.dm_db_index_usage_stats WHERE database_id = DB_ID();

Vermeide doppelte oder redundante Indizes – manchmal existieren mehrere Indizes, die fast identisch sind und unnötig Speicher verbrauchen. Denke an Write-Heavy-Workloads: Zu viele Indizes können INSERT- und UPDATE-Operationen verlangsamen, weil SQL Server jeden Index aktualisieren muss.

Automatisiere die Index-Wartung mit bewährten Lösungen wie dem Ola Hallengren Maintenance Script. Dieses Skript bietet eine umfassende Verwaltung für Index-Reorganisation und -Rebuilds und wird von vielen DBAs weltweit eingesetzt:

EXECUTE dbo.IndexOptimize
    @Databases = 'ALL',
    @FragmentationLevel1 = 5,
    @FragmentationLevel2 = 30;

Weitere Infos und das Skript findest du hier: Ola Hallengren – SQL Server Maintenance Solution

Fazit: Dein Index sollte zur Abfrage passen!

• Halte deine Indizes schlank und vermeide unnötige Spalten.
• Achte auf die Reihenfolge der Spalten – SQL Server arbeitet von links nach rechts.
• Überwache die Fragmentierung und optimiere regelmäßig.
• Nutze Covering Indizes, um teure Lookups zu sparen.
• Analysiere regelmäßig die Nutzung deiner Indizes, um unnötige oder ineffiziente Indizes zu vermeiden.

Wenn du deine Index-Strategie richtig aufsetzt, läuft dein SQL Server spürbar schneller – und du ersparst dir nervige Performance-Probleme. Falls du Fragen hast oder über ein kniffliges Index-Problem reden willst, schreib mir gerne!

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.