SQL Server : Index Leitfaden Teil 1 – Indizes für Rookies

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.

 

Welche Indizes gibt es ?

Spontan fallen mir folgende ein (XML und Geodaten Indizes mal ausgenommen):

  • Gefilterter Index
  • Partitionierter Index
  • Clustered Index
  • Non Clustered Index
  • Index mit eingeschlossenen Spalten
  • zusammengesetzter Index
  • eindeutiger Index
  • gruppierter Index
  • nicht gruppierter Index
  • abdeckender Index

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!

 

Non clustered 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.

 

Gruppierter 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.

 

 

Erkenntnisse
  • Dadurch, dass der Gruppierte Index die Tabelle selbst ist, kann es ihn nur einmal pro Tabelle geben!
  • Der Gruppierte Index erreicht seine “Bestform” bei Abfragen, die Bereiche Umfassen (alle Kunden zwischen A und C), da diese physikalisch direkt nebeneinander gespeichert wurden!
  • Der Nicht gruppierte Index ist besonders bei Abfragen die relativ wenig Datensätze (besser einen einzigen) zurückgeben!
  • Der Nicht gruppierte Index verliert an Leistung, sofern relativ viele Datensätze zurückgeben werden!
    Beispiel: Eine Heap besteht aus 8 Seiten. Auf diesen 8 Seiten kommt der Nachname 7 mal in jeweils verschiedenen Seiten vor. Würde man nur den Heap scannen, bräuchte man 8 Seiten um alles Datensätze zu bekommen. Würde der Index verwendet werden, müsste man 3 Index Seiten durchlaufen und zusätzlich die 7 Seiten des Heaps lesen, um das Ergebnis zuliefern. Also 10 Seiten. Das sind 2 Seiten mehr, als der Heap/Tabellen tatsächlich hat!!
  • Ein Primärschlüssel wie die KundenNr wird standardmäßig als Clustered Index angelegt. Ein eindeutiger Wert! Gesucht wird allerdings oft nach eine bestimmten KundenNr. Der Gruppierte Index ist sicherlich nicht langsam, aber verschwendet eingesetzt, da er nur einmal verwendet werden kann. Besser wäre er vielleicht für das Land, den Ort oder PLZ gewesen! Oder wie ist es etwa bei eine BestellTabelle. Suchen wir nach BestellNummern zwischen 10000 und 20000 häufig oder eher doch nach der Bestellung dieses Jahres? Das Bestelldatum ist ein idealer Kandidat für gruppierte Indizes. Die BestellNummer dagegen für den Nicht gruppierten.

Im Teil 2 Teil 2 – Vergabe von Indizes klären wir, auf welche Kleinigkeiten man bei der Vergabe der Indizes aufpassen sollten…

Fumus

Share
Published by
Fumus

Recent Posts

SQL Server 2019 – static data masking – Du Opfer!

In SQL Server 2016 wurde das sog. dynamic data masking eingeführt. Eine Möglichkeit Daten bei…

5 Jahren ago

MinRole – Oder wie alles etwas einfacher wird

Seit Sharepoint Server 2007 präsentiert sich die Installation immer auf die gleiche Weise. Gerade mal,…

8 Jahren ago

Schritt für Schritt: SQL 2016 – Dynamic Data Masking

Es weihnachtet! Gerade bekam ich von einer Kollegin Plätzchen angeboten mit der Größe eines Diskus…

8 Jahren ago

Schritt für Schritt: SQL Server 2016 – temporal tables

Nein, bitte nicht verwechseln: temporal tables haben nichts zu tun mit temporary tables table variables…

9 Jahren ago

SQL Server 2016 Schritt für Schritt–Installation und First Look

SQL Server 2016.. habe ich schon erwähnt, dass ich den ziemlich cool finde? Wollen wir…

9 Jahren ago

SQL Server 2016 – CTP2

Nach langer Zeit wieder mal eine Artikel von mir.. der mich besonders erfreut. SQL Server…

9 Jahren ago