Die fünf wichtigsten Überlegungen zum Datenbankindexdesign in SQL Server

Datenbankindizes werden verwendet, um verschiedene Tabellenoperationen zu beschleunigen. Bevor Sie jedoch einen Index erstellen, ist es wichtig zu wissen, ob Sie wirklich einen Index benötigen. Und wenn Sie einen Index erstellen müssen, was sind die wichtigen Punkte, die Sie beachten müssen? Hier kommt das Datenbank-Index-Design ins Spiel.

Dieser Artikel zielt darauf ab, diese Fragen zum Datenbankindexdesign zu beantworten und einige der wichtigsten Überlegungen zu beleuchten, die ein Datenbankentwickler beim Entwerfen eines Indexes berücksichtigen sollte.

1. Tabellengröße

Die erste Frage, die sich ein Datenbankentwickler stellen muss, bevor er einen Index erstellt, ist, ob die Tabelle groß genug ist, um Indizes effizient zu verwenden. Wenn die Tabellengröße klein ist, kann die SQL Server-Engine die vollständige Tabelle schneller scannen, als die Tabelle über einen Index zu durchsuchen. Indizes haben in einem solchen Fall keinen Nutzen und erzeugen einen Overhead bei der Durchführung von Datenbankoperationen.

2. Spaltentypen

Indizes sollten für eine Primärschlüsselspalte oder eine beliebige Spalte erstellt werden, die eindeutige Werte enthält und die eine NOT NULL-Einschränkung hat. Darüber hinaus ist es ratsam, Indizes für numerische Spalten zu erstellen, da numerische Spalten im Vergleich zu nicht numerischen Spalten tendenziell eindeutigere Werte haben. Ein schlechtes Datenbankindexdesign verwendet Indizes für Spalten mit sehr wenigen eindeutigen Einträgen und kann zu sehr zeitaufwändigen Abfragen führen.

Stellen Sie sich eine Tabelle mit dem Namen Patienten vor, die Hunderttausende von Datensätzen enthält. Die Patiententabelle würde eine Spalte namens „Geschlecht“ enthalten, die nur zwei eindeutige Werte „Männlich“ und „Weiblich“ haben kann. Wenn Sie einen Index für die Spalte „Geschlecht“ erstellen, werden die Datensätze in aufsteigender oder absteigender alphabetischer Reihenfolge sortiert.

Wenn Sie also eine Million Datensätze in der Patiententabelle haben und die Anzahl männlicher und weiblicher Patienten gleich ist, haben im Index die erste halbe Million Datensätze das Geschlecht „Weiblich“ und die zweite halbe Million das Geschlecht „Männlich“. Wenn Sie nun nach einer Frau suchen möchten, die in der 490.000. Zeile der weiblichen Datensätze vorhanden ist, muss die SQL Server-Engine 490.000 Datensätze durchsuchen. Andererseits kann die Suche mit eindeutigen numerischen Werten extrem schnell sein, da SQL Server-Indizes in Form von B + -Bäumen gespeichert werden und daher numerische Werte in den Baumknoten Datenbankoperationen beschleunigen können.

3. Anzahl der Indizes

Offiziell können Sie für jede Datenbanktabelle einen Clustered-Index und beliebig viele Non-Clustered-Indizes erstellen. Es ist jedoch ein gutes Datenbankindexdesign, einen gruppierten Index und nur eine begrenzte Anzahl absolut notwendiger nicht gruppierter Indizes zu erstellen. Das Erstellen zu vieler nicht gruppierter Indizes kann Aktualisierungs- und Einfügevorgänge tatsächlich verlangsamen, da alle zugehörigen Indizes aktualisiert werden müssen, wenn ein Datensatz aktualisiert oder eingefügt und ein Spaltenwert geändert wird.

Stellen Sie sich ein Szenario vor, in dem wir zwei nicht gruppierte Indizes haben, der erste Index sortiert die Datensätze nach Alter und der zweite Index sortiert die Datensätze nach Geschlecht und Alter.

Hier ist der erste Index:

Und hier ist die zweite:

Wenn nun ein Datensatz mit dem Alter 40 aus irgendeinem Grund auf das Alter 15 aktualisiert werden muss, muss der erste Index aktualisiert werden, um den Datensatz von der 7. Position (40) an die zweite Position zu verschieben, damit der Index sortiert bleibt. Ähnlich wird im zweiten Index der Datensatz im vierten Index in den zweiten Index verschoben. Es muss viel umgebaut werden. Daher ist es ratsam, die Anzahl der Indizes für die Spalten, die regelmäßig aktualisiert werden, auf ein Minimum zu beschränken, wenn Sie über das Design von Datenbankindizes nachdenken. Außerdem sollte eine Spalte nicht in mehreren nicht geclusterten Indizes verwendet werden.

4. Speicherort der Indizes

Der Speicherort eines Index kann sich auf die Leistung der Abfragen auswirken, die den Index verwenden, und ist daher auch Teil eines guten Datenbankindexdesigns. Standardmäßig wird ein gruppierter Index in derselben Dateigruppe gespeichert wie die Tabelle, für die der Index erstellt wird. Bei nicht gruppierten Indizes kann der Index in derselben Dateigruppe oder in verschiedenen Dateigruppen gespeichert werden, die sich über mehrere Festplattenlaufwerke erstrecken. Die Abfrageleistung von Non-Clustered-Indizes kann erheblich verbessert werden, indem Non-Clustered-Indizes auf mehreren Plattenlaufwerken gespeichert werden. Denn durch die Verteilung der Daten auf verschiedene Bereiche des Laufwerks wird die Ein-/Ausgabeleistung der Abfrage verbessert.

Der Standardspeicherort von Indizes kann auch geändert werden, indem ein Wert für die Option FILLFACTOR angegeben wird. Da Indizes physisch in Form von B+-Bäumen gespeichert werden, werden die Indexdaten auf Blattseiten gespeichert. Mit der Option FILLFACTOR können Sie den Prozentsatz der zu füllenden Seiten auf Blattebene festlegen. Wenn Sie beispielsweise den Wert von FILLFACTOR auf 70 % setzen, werden nur 70 % des gesamten Speicherplatzes der Seite auf Blattebene mit Indexdaten gefüllt. Die restlichen 30 % werden in Zukunft für das automatische Wachstum von Indexdaten verwendet.

5. Indextypen

Eine weitere äußerst wichtige Überlegung beim Entwurf von Datenbankindizes ist der zu verwendende Indextyp. In einem früheren Artikel (fügen Sie einen Link zum Artikel „When to use Clustered or Non-Clustered Index“ hinzu) habe ich den Unterschied zwischen Clustered- und Non-Clustered-Indizes erklärt. Ich habe auch erklärt, was sie sind und wie sie verwendet werden können. Die Entscheidung, ob man sich für einen geclusterten oder einen nicht geclusterten Index entscheidet, ist entscheidend und sollte sorgfältig durchdacht werden.

Die folgenden Punkte sollten bei der Auswahl des Indextyps beachtet werden.

1. Verwenden Sie für die Spalten, die in SELECT/JOIN/GROUP BY/BETWEEN-Abfragen verwendet werden, gruppierte Indizes.
2. Verwenden Sie nicht gruppierte Indizes für Spalten, bei denen Sie nur Werte aus dieser bestimmten Spalte und nicht aus den anderen Spalten derselben Zeile abrufen möchten. SELECT-Abfragen, die mehrere Datensätze mit einem nicht gruppierten Index abrufen, können langsam sein, da die SQL Server-Engine zuerst die Spaltenwerte durchsucht, auf denen der Index erstellt wird, und dann unter Verwendung der Zeilenreferenz für den Spaltenwert die Datensätze aus tatsächlichen Datenbanktabellen abgerufen werden .
3. Verwenden Sie für die Spalten, die häufig INSERT- und UPDATE-Operationen unterzogen werden, einen nicht gruppierten Index. Stellen Sie sicher, dass Sie nicht eine Spalte in mehreren nicht gruppierten Indizes verwenden, da dies Aktualisierungsabfragen verlangsamen kann. Clustered-Indizes können für INSERT/UPDATE-Operationen langsam sein, da die komplette Zeile aktualisiert werden muss, anstatt nur ein einzelner Spaltenwert, wie es bei Non-Clustered-Indizes der Fall ist.
4. Da Sie nur einen geclusterten Index erstellen können, verwenden Sie in diesem Fall, wenn Sie mehrere Indizes benötigen, nicht geclusterte Indizes. Wenn der Festplattenspeicher jedoch ein großes Problem darstellt, sollten Sie die Anzahl der nicht geclusterten Indizes auf ein Minimum beschränken.

Andere Überlegungen

Obwohl dies die fünf wichtigsten Teile des Datenbankindexdesigns sind, sind sie nicht alles. Es ist wichtig, die richtige Reihenfolge der Spalten in Indizes anzugeben. Als Faustregel gilt, dass die Spalten, die für die Entscheidungsfindung in WHERE-Klauseln verwendet werden, und Bedingungen wie größer als (>), kleiner als (<) usw. vor den Spalten platziert werden sollten, die nicht in diesen Klauseln enthalten sind. Bei mehreren Spalten in der WHERE-Klausel sollten die markantesten Spaltennamen frühestens in der Indexdefinition erwähnt werden.

Neben dem Datenbankindexdesign spielt auch das Abfragedesign eine wichtige Rolle bei der effizienten Nutzung des Indexdesigns. Versuchen Sie für eine optimierte Indexpflege weniger Abfragen zu schreiben, die eine größere Anzahl von Tabellenzeilen betreffen, anstatt mehrere Abfragen zu schreiben, die auf einer kleinen Anzahl von Zeilen ausgeführt werden.

Schlussfolgerung

In diesem Artikel werden einige der wichtigsten Überlegungen erläutert, die ein Datenbankentwickler bei der Betrachtung des Datenbankindexdesigns berücksichtigen muss. Der Artikel erläutert auch die Gründe für diese Überlegungen und enthält weitere Vorschläge, um sicherzustellen, dass Ihr Datenbankindex-Design effizient ist.