Indizes sind Top Beschleuniger für T-SQL! Ja und Nein. Tatsache ist, dass Indizes Abfragen enorm, wir sprechen von 30 Sekunden auf 1 Sekunde – reduziert werden können. Tatsache ist allerdings auch, dass Indizes “schmerzen”, wenn es um Inserts, Update und Delete geht. Indizes müssen daher mit Bedacht und Sorgfalt gewählt werden. Allerdings welche Kriterien sollte man dafür verwenden? Hier zu das kleine Index 1 mal 1.
Spontan fallen mir folgende ein (XML und Geodaten Indizes mal ausgenommen):
Soviel?? Nein. Effektiv gibt es nur zwei davon: den Clustered (im deutschen gruppierter Index) und den nicht gruppierten Index (der non Clustered Index). Ok.. was ist der Unterschied. Alle anderen Indizes sind effektiv nur Optionen auf einen Nicht gruppiertem Index!
Indizes werden wie Tabellen in Seiten zu 8 kb verwaltet. Jede Seite hat einen Verweis, welche Seite davor und danach kommt. Eine Tabelle ohne einen gruppierten Index nennt man Heap.. Ein Haufen an unsortierten Daten. Der nicht gruppierte Index schafft hier Abhilfe.
Der Index ist simpel gesagt, mit einem Telefonbuch vergleichbar. Wir holen uns wenige Information (Spalten), listen diese in sortierter Form auf und verweisen auf das Original. Effektiv werden also Werte aus den Spalten (Familienname, KundenNr o.ä.) aus den Tabellen herauskopiert und mit einem Verweis versehen, der den genau Ort des Originaldatensatz belegt.
Über die sortierten Daten, wird ein sogenannter B-Baum gelegt, der jeweils vereinfacht gesagt eine “Links-Rechts” Entscheidung trifft, wo die Daten zu finden sind. Am Ende des Index Baumes findet die Daten und die Angabe, wo der tatsächliche Datensatz zu finden ist. Hierbei bedeuten die Zahlen bspw. 1:708:02: Datei 1, Seite 708 Zeile 2.
Wieso ist der Index nun so schnell? Der Index aus dem Beispiel benötigt nur 3 Ebenen um den Datensatz finden. Das bedeutet faktisch, dass er – egal was man sucht – definitiv auch nur 3 Seiten zum finden benötigt. Auch dann, wenn unsere Tabelle aus 1000 Seiten bestünde.
Hätten wir den Index nicht, müssten wir den kompletten Heap durchlaufen um sich zu sein allen Daten zu bekommen.Also statt 1000 Seiten nur 3 Seiten über den Index.
Der Gruppierte Index hat effektiv keinen Heap mehr. Der gruppierte Index ist !! nu die Tabellen. Die Datensätze werden in physikalischer Form sortiert abgelegt. Somit existieren auch keine Kopien der Datensätze oder Verweise (1:708:02). Der Gruppierte Index hat ebenfalls wie der Nicht gruppierte Index einen B-Baum über seinen sortierten Daten, um schneller Treffer zu erreichen.
Im Teil 2 Teil 2 – Vergabe von Indizes klären wir, auf welche Kleinigkeiten man bei der Vergabe der Indizes aufpassen sollten…
In SQL Server 2016 wurde das sog. dynamic data masking eingeführt. Eine Möglichkeit Daten bei…
Seit Sharepoint Server 2007 präsentiert sich die Installation immer auf die gleiche Weise. Gerade mal,…
Es weihnachtet! Gerade bekam ich von einer Kollegin Plätzchen angeboten mit der Größe eines Diskus…
Nein, bitte nicht verwechseln: temporal tables haben nichts zu tun mit temporary tables table variables…
SQL Server 2016.. habe ich schon erwähnt, dass ich den ziemlich cool finde? Wollen wir…
Nach langer Zeit wieder mal eine Artikel von mir.. der mich besonders erfreut. SQL Server…