Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL Server: Performance-Optimierung

Welche Arten von Indizes spielen heute eine Rolle?

Testen Sie unsere 2019 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Hier finden Sie eine Erläuterung der wichtigen Indexarten Heap, (Non-)clustered Index, Clustered Columnstore Index und Hash Index/ Range Index.
09:27

Transkript

So, nun aber zu den Indizes, und als erstes sei die Frage geklärt: Was für Arten von Indizes gibt es eigentlich? Die erste Möglichkeit, die ich haben kann, ist schlicht überhaupt kein Index. Das nennt der SQL-Server dann Heap, ein bisschen angelehnt an der Tatsache, dass, wenn ich einen Heap habe, also keinen Index, keinen Clustered Index eigentlich, um genau zu sein, dann bedeutet das im Wesentlichen, die Daten werden einfach übereinander geschaufelt, was so relativ schnell funktionieren kann, aber natürlich ein Albtraum ist, wenn ich nach Daten suche. Und insofern ist das quasi der Anti-Index an der Stelle, und sei deswegen auch erwähnt. Als nächstes gibt es den Non Clustered Index. Das bedeutet: Das ist ein Index, der gewisse Spalten indexiert und damit eine Suche über diese Spalten möglichst effizient gestaltet. Technisch ist das ein B-Tree. Das bedeutet: Der SQL-Server sucht sich in einer baumähnlichen Struktur möglichst schnell die Zeilen, die dem Index entsprechen. Non Clustered Indizes werden im Deutschen übrigens als nicht gruppierte Indizes bezeichnet. Dann gibt es einen Clustered Index, und der Clustered Index, im Deutschen immer gruppierter Index, ist der Index, der auch gleichzeitig die physikalische Reihenfolge der Daten in der Tabelle ablegt, das heißt sobald ich einen Clustered Index habe, sind die Daten nicht mehr wie im Heap relativ zufällig angeordnet, so wie sie gerade reingekommen sind, sondern haben eine Struktur und werden genau nach diesem Index entsprechend einsortiert an der Stelle. Logischerweise kann es nur einen Clustered Index geben, weil ich die Daten physikalisch natürlich nur in einer bestimmten Reihenfolge ablegen kann, und nicht gleichzeitig in zwei verschiedenen Reihenfolgen. Das geht nicht. Dann gibt es Clustered ColumnStore Indizes, ab SQL Server 2014, und das bedeutet, dass die gesamte Zeile entsprechend indexiert wird. Und "ColumnStore" deswegen, weil die Daten nicht mehr zeilenweise, sondern spaltenweise abgelegt werden, und gleichzeitig auch komprimiert, und wenn ich mir eine Tabelle vorstelle, wo möglicherweise einzelne Änderungen an Zeilen durchgeführt werden und die dann sozusagen in einer Art Historie abgelegt werden, dann ändert sich von Zeile zu Zeile möglicherweise nicht so besonders viel, sodass die Komprimierung relativ hoch sein kann. Das werden wir aber später sehen, was da durchaus möglich ist. Dann gibt es sogenannte Hash und Range Indizes. Die stehen allerdings nur für In-Memory Optimized Tables zur Verfügung, das heißt wenn ich eine Tabellenstruktur oder eine Tabellentechnik habe, die für den Speicher optimiert ist, für den RAM optimiert ist, habe ich hier andere Arten von Indizes, um auf Informationen zuzugreifen, und das ist entsprechend Hash oder auch der Range Index an der Stelle. So, schauen wir uns doch mal an, was für die einzelnen Indexarten denn so charakteristisch ist. Zunächst einmal der Heap, der wie gesagt eigentlich ja eher der Anti-Index ist, das heißt da habe ich eine Tabelle, die hat allerdings keinen Clustered Index. Die Reihenfolge der Zeilen wird in der Regel so abgelegt wie sie den reinkommen an der Stelle. Und ich kann theoretisch auf einem solchen Heap auch einen Non Clustered Index haben. Das ist möglich, vielleicht ein bisschen unüblich, aber zumindest denkbar. Dann gab es den Non Clustered Index, und das ist in der Tat wirklich auch ein richtiger Index, das heißt die Inhalte werden in eine spezielle Speicherstruktur geschrieben, und bei Suchen kann der SQL-Server sich dieser Struktur, diesem B-Tree, entsprechend bedienen und Daten möglichst schnell finden, ohne vielleicht in der Tat auf die Tabelle zuzugreifen. Das ist möglicherweise nur dann notwendig, wenn später ein Zugriff auf die einzelnen Spalten dieser Tabelle stattfinden soll, die nicht im Index vertreten sind. Maximal kann es 999 Non Clustered Indizes pro Tabelle geben. Das würde ich jetzt mal großzügig als "beliebig viel" bezeichnen, durchaus eine Anzahl, auf die man in der Praxis wahrscheinlich nicht wirklich stößt. Und die maximale Größe eines Index wiederum sind 1700 Bytes. Also, da muss man anfangen, die Größe der einzelnen Spalten zu berechnen. 1700 ist relativ, sagen wir mal, großzügig definiert. Es gibt Möglichkeiten, diese Grenze auch noch zu sprengen. Man kann dann einzelne Spalten in Hash-Werte umrechnen, diese dann wiederum später indizieren und solche Tricks machen, aber 1700 Bytes, vertrauen Sie mir, ist durchaus eine relativ groß und großzügig bemessene Datenmenge für einen Index. Dann gab es da den Clustered Index, oder den gruppierten Index, der die physikalische Reihenfolge der Zeilen festlegt. Und letztendlich gibt es den geflügelten Satz, der sagt: Der Clustered Index ist die Tabelle, und die Tabelle ist gleichzeitig auch der Clustered Index. Das stimmt insofern, als dass die physikalische Reihenfolge der einzelnen Zeilen natürlich letztendlich wirklich die Tabelle repräsentiert an der Stelle. Es kann nur einen Clustered Index geben. Wie gesagt, es ist nicht möglich, Daten gleichzeitig auf zwei verschiedene Arten und Weisen zu arrangieren. Es muss entweder diese Sortierung oder es muss eine andere sein, und die Reihenfolge oder eine andere Reihenfolge. Es kann nicht gleichzeitig mehrere geben. Das geht nicht. Hier gibt es ebenfalls ein Limit, und zwar von 900 Bytes. Das klingt jetzt auch nicht besonders viel, reicht aber wirklich aus, das heißt kein Clustered Index kann mehr als 900 Bytes umfassen, was nicht bedeutet, dass die ganze Zeile nur 900 Bytes haben darf, sondern nur die Spalten, die auch in den Clustered Index mit aufgenommen wurden. Insofern: Auch hier sind 900 Bytes für die allerallermeisten Fälle wirklich absolut ausreichend. Der Clustered Columnstore Index ist ein bisschen etwas anderes. Hier wird die gesamte Zeile entsprechend indexiert. Also, ich kann nicht sagen, welche einzelnen Spalten ich haben möchte, sondern die komplette Zeile wird in den Index umgewandelt, und die Daten werden auch nicht zeilenweise abgelegt, wie es sonst der Standard beim SQL-Server ist, sondern spaltenweise. Und entsprechend ist die Komprimierung, die in vielen Fällen zu erwarten ist, durchaus relativ üppig. Sie werden gleich an den Grafiken sehen, die das so ein bisschen belegen. Das heißt, ich kann diesen Index dafür nutzen, um zum Beispiel historische Daten abzulegen. Für Daten allerdings, die ich häufig ändere oder auf die ich sehr häufig zugreife, ist dieser Index nicht ganz so gut geeignet, weil die Performance jetzt nicht unbedingt so gut ist. Aber letztendlich, wenn ich wie gesagt historische Daten habe oder sehr sehr umfangreiche Daten, wo ich wirklich ohne Komprimierung mehrere Terabyte brauche, kann ich das Ganze auf eine relativ übersichtliche Datenmenge zusammendampfen, was natürlich dann wiederum bedeutet, dass ich bei der Performance ein bisschen Abstriche machen muss. Ab SQL Server 2016 können Sie auch sekundäre Indizes anlegen. Das bedeutet: Ab dieser Version ist es möglich, neben dem Clustered Columnstore Index noch einen zweiten, dritten und vierten Index oder weitere Indizes anzulegen, über die dann entsprechend gesucht werden kann. Mit SQL Server 2014 war dies nicht möglich. Da war der Clustered Columnstore Index der einzige Index auf dieser Tabelle, und ich konnte keinen zweiten anlegen. Insofern: Ein bisschen optimaler wird der Umgang mit diesen Clustered Columnstore Indizes auf jeden Fall ab SQL Server Version 2016. Dann ein paar Worte über Hash Index beziehungsweise Range Index. Dies sind zwei verschiedene Arten von Indizes, die nur für Tabellen definiert werden können, die entsprechend Memory Optimized sind, das heißt die eigentlich nur dafür da sind, im Speicher zu existieren. Dafür gibt es zwei verschiedene Varianten, und zwar einmal solche, die wirklich nur im Speicher existieren, wo auch keine Persistierung auf die I/O-Systeme stattfindet. Das bedeutet: Neustart und die Tabelle ist wieder leer. Und es gibt die Variante, dass ich die Daten, die sich in diesen Memory Optimized Tables befinden, entsprechend auf die I/O-Systeme persistiere, das heißt ein Neustart würde bedeuten: Die Tabellen werden beim Start der Datenbank direkt ins RAM geladen, und zwar tutto completti, und das bedeutet: Wenn nicht genug RAM da ist, kann letztendlich die Datenbank nicht gestartet werden, weil dem SQL-Server schlicht und ergreifend dann der Speicher ausgeht. Bei In-Memory-Tabellen sei angemerkt, dass es hier ein abweichendes Transaktionsverhalten gibt. Das hat jetzt nichts mit der Performance zu tun, aber falls Sie sich überlegen, diese Art von Tabellen zu benutzen, werden Sie auf der einen Seite von ziemlich guter Performance belohnt. Zum anderen aber müssen Sie damit rechnen, dass sich hier einiges an Spielregeln ändert. Normalerweise ist es so, wenn zwei Prozesse auf eine Tabelle zugreifen und Prozess 1 macht eine Änderung, Prozess 2 möchte entsprechend auf die Zeile, die geändert wird, zugreifen, dann wartet Prozess 2 so lange, bis entweder Prozess 1 fertig ist oder letztendlich Prozess 2 schlicht in einen Timeout ausläuft, weil Prozess 1 einfach so lange gebraucht hat, um die Änderung durchzuführen oder schlicht die Sperre so lange noch offen gehalten hat. Bei einem Memory Optimized Table sieht es anders aus. In dem Fall würde Prozess 1 nach wie vor die Änderung machen. Prozess 2 würde versuchen, auf die Zeile zuzugreifen, und just in dem Moment, in dem Prozess 2 auf die Zeile zugreift und keinen sofortigen Zugriff bekommt, gibt es sofort einen, quasi einen Timeout, einen Fehler an der Stelle, und das einzige, was Prozess 2 an der Stelle noch übrig bleibt, ist, es noch einmal zu versuchen, und entsprechend, das ist auch wirklich das Best Practice, das heißt hier müssen Sie ein bisschen damit rechnen, wenn Sie In-Memory Optimized Tables verwenden, dass Sie Ihre Anwendungen so weit bauen, dass Sie in der Tat in der Lage sind, einfach gewisse Operationen nochmal durchzuführen.

SQL Server: Performance-Optimierung

Lernen Sie den Umgang mit Indizis und Tools, um die Leistungsfähigkiet Ihrer SQL Server Datenbank effektiv zu erhöhen.

3 Std. 20 min (32 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:04.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!