# Warum ist es suboptimal viele Indexe auf eine Datenbanktabelle zu setzen?



## Maik.Neumann (3. Jul 2014)

Hallo !

Ich habe einmal gehört, dass es angeblich ganz schlechter Stil sein soll, wenn ich ganz viele  Indexe auf eine Datenbanktabelle setzen soll (also quasi fast auf jede Tabellenspalte einen Index).

Bisher habe ich noch nciht ganz verstanden, warum das so ist? Ich habe nur gehört, dass es angeblich teuer sein soll und die Performance meiner Abfragen sogar in die Knie zwingen könnten.

Ich wäre sehr dankbar, wenn mir hier jemand etwas dazu sagen könnte.

Danke und Gruß


----------



## Deros (3. Jul 2014)

Ein Index ist ja nichts weiter als eine physische Sortierung, er hilft also beim lesen und hindert beim schreiben. Beim Schreiben muss er halt erst die richtige stelle finden wo der Datensatz hingehört. 
Sinn macht es eigentlich nur auf Feldern über die zugegriffen (where, join) oder sortiert (order by, group by, distinct) wird.


----------



## Ruzmanz (3. Jul 2014)

Hätte das ein bisschen anders formuliert. Deine Tabelle verbraucht viel Speicher auf der Festplatte. Für jeden Festplatten-Block-Zugriff benötigst du sehr viel Zeit (z.B. 10ms). Ob das nun eine SSD oder HDD ist, spielt dabei kaum eine Rolle. Wenn du nun nach 
	
	
	
	





```
username = "RuZmanz"
```
 suchst, muss du in jeden Festplattenblock (der Tabelle User) reinschauen. Die Zeit für den Vergleich, ob der Inhalt tatsächlich "RuZmanz" ist, ist so gering, dass du den ersteinmal vernachlässigen kannst. Fakt ist, dass wir sehr langsam filtern können, aber dafür sehr schnell einen neuen Eintrag an das Ende der Tabelle einfügen können. Im Normalfall wird aber eher gefiltert, als permanent zu speichern.

Ein neuer Index bedeutet, dass die Tabelle (zum Teil) auf der Festplatte zusätzlich sortiert abgespeichert wird. Zum Beispiel "Wohnort; Nachname; Vorname; TelNr -> PersonID". Simple ausgedrückt kann nun der Computer genau so wie der Mensch sehr schnell Einträge finden, ohne die ganze Tabelle zu durchsuchen. Greife ich zufällig auf die Mitte der Tabelle zu und bekomme ein "Darmstadt", dann weis ich sofort, dass Berlin in der ersten Hälfte steht => 50% der Tabelle muss nicht gelesen/in den RAM abgelegt werden. Indirekte Vorteile entstehen auch beim Count. Wenn ich nun alle TelNr mit einer "6" am Anfang finden möchte, kann ich diese im Index nachzählen. Ich muss dafür den kompletten Index in den RAM laden, ABER der Index ist von der Speichergröße viel kleiner als die Tabelle Person mit 1000 Tabellenfeldern.

Da der Index wie bereits gesagt wurde auf der Festplatte abgespeichert wird, dauert das Insert/Delete etwas länger. Immerhin muss jeder Index der Tabelle aktualisiert werden.

Wann lohnt sich ein Index? Der Wert der Spalte wird oft gefiltert. Zum Beispiel bei JOIN x == y oder WHERE x = 'abc'. Wenn ich einen Index mit [a, b] habe, dann kann ich nach (a) oder (a und b) filtern. Versuche ich auf nach (b) zu filtern bringt mir der Index fast nichts. (Ausgenommen count und ein paar Spezialfälle). Bei einem Telefonbuch zum Beispiel ändern sich sehr wenig Daten, aber dafür wird extrem viel gesucht. Dort kann es sich lohnen für viele Suchoptionen einen Index anzulege ...


----------



## Maik.Neumann (3. Jul 2014)

Danke für die Beiträge !



> Da der Index wie bereits gesagt wurde auf der Festplatte abgespeichert wird, dauert das Insert/Delete etwas länger. Immerhin muss jeder Index der Tabelle aktualisiert werden.



Also wäre das quasi das Hauptargument, warum es schädlich wäre, wahllos Indexe auf eine Datenbanktabelle zu legen?


----------



## ARadauer (3. Jul 2014)

Das Schreiben dauert länger und es braucht mehr Speicher.


----------

