Grundsätzlich - kann DB mehrere Indizes kombinieren?

[BlackbirdBerlin]

Hi Frankyboy,
grundsätzlich ergibt es viel Sinn, für eine Tabelle mehrere Indizes zu definieren, die verschiedene Abfragen optimieren.
Die Frage war aber, ob es Sinn ergibt, mehrere "einfeldige" Indizes anzulegen, anstelle spezieller Indizes mit mehreren Feldern und darauf zu bauen, dass die DB diese in Kombination verwendet (was wohl unter dem Schlagwort Bitmapped Indexes so zu sein scheint).
Und wenn es die Steigerung von optimal gäbe, dann wäre es wohl am "optimalsten", wenn man einen konkreten Index definiert, welcher die Schlüsselfelder der Abfrage indiziert.
Grüße,
Tim

[frankyboy1974]

hallo Blackbird,

ich verstehe die Frage jetzt immer noch nicht,

Zitat:

Wie realisieren Datenbanken einen Index???

Warum legt nicht die Datenbank automatisch auf jedes Feld einen Index an. Dann würde die Suche nach diesem Feld wohl schneller funktionieren?? Und wenn ich nach zwei Felder suche, dann kombiniert die DB einfach die beide Inizes und ist dann immer noch schneller als ein Tablescan? Also mein Gedanke wäre immer noch, bei der ersten Abfrage veruchst du einen Index zu erwischen, und den Rest programmierst du selbst.

mfg

[mkinzler]

Ein Index beschleunigt die Suche, verlangsamt aber Insert/Update/Delete Vorgänge, weil auf Grund dieser ja Aktualsierung der Indizes notwendig wird. Deshalb wird automatisch nur ein Index für den Primärindex erzeugt.

[Sir Rufo]

Jeder Index auf einer Tabelle ist intern eine weitere Tabelle mit den Inhalten der indizierten Felder. Darum macht z.B. ein Index mit allen Feldern keinen Sinn, weil ich damit nur die Tabelle dupliziere.

Jeder Index belegt auch Speicher. Jeder Index muss wie die Tabelle aktualisiert werden. Mit einem Index-Wildwuchs kann ich den Plattenplatz verbraten und die Einfüge-Geschwindigkeit in den Keller drücken.

Es ist also ein Balance-Akt zwischen Speicherplatz und Abfrage-/Einfüge-Geschwindigkeit.

Für riesige Datenmengen mit vielen Abhängigkeiten werden für die Auswertung auch gerne mal separate Systeme genutzt. Die sind dann zwar nicht unbedingt absolut auf dem aktuellsten Stand, dafür aber bei der Abfrage höllenschnell. Wenn ich wissen will was letzten Monat passiert ist, dann ist mir aber der Stand von vor einer Sekunde so was von egal.

[BlackbirdBerlin]

Zitat von Sir Rufo:

...Darum macht z.B. ein Index mit allen Feldern keinen Sinn, weil ich damit nur die Tabelle dupliziere.

Kann man uneingeschränkt so nicht gelten lassen, finde ich.

Es müsste heißen: Darum ergibt z.B. ein Index mit allen Feldern in identischer Reihenfolge keinen Sinn, weil ich damit nur die Tabelle dupliziere.

Beispiel:

Code:

 Tabelle:
  BelegNr
  BelegJahr
  Kunde
  Artikel

 Index:
  Kunde
  Artikel
  BelegJahr
  BelegNr

Hier würde der Index m.E. durchaus Sinn ergeben, obwohl alle Felder enthalten sind!

Aber auch hier lasse ich mich gern eines Besseren belehren

Viele Grüße und sehr vielen Dank für Eure Beteiligung!
Tim

[mm1256]

Zitat von BlackbirdBerlin:

...Die Frage war aber, ob es Sinn ergibt, mehrere "einfeldige" Indizes anzulegen, anstelle spezieller Indizes mit mehreren Feldern und darauf zu bauen, dass die DB diese in Kombination verwendet (was wohl unter dem Schlagwort Bitmapped Indexes so zu sein scheint).
Und wenn es die Steigerung von optimal gäbe, dann wäre es wohl am "optimalsten", wenn man einen konkreten Index definiert, welcher die Schlüsselfelder der Abfrage indiziert.

Nun, ich bin ja ein eher praktisch denkender Mensch, und darum würde ich das Problem einfach mal eben auch von der praktischen Seite angehen. Denn, so schön die Diskussion hier mitzulesen ist, und so unterschiedlich die DB's das handhaben, Klarheit wird letztendlich nur ein Test bringen.

Da die Struktur der DB bekannt ist, ist das Anlegen von ein paar Mio Datensätzen in drei Test-Tabellen in allen drei Varianten (Original wie beim Kunden, mit Einzel-Index und mit zusammengesetztem Index) keine Hexerei.

Wenn meine Annahme stimmt, hau ich dem Kunden das Ergebnis um die Ohren und bin der King. Wenn nicht, verkriech ich mich in mein stilles Örtchen und warte bis der Anfall vorüber ist

[BlackbirdBerlin]

Hi Otto,

das Problem beim Mal-Eben-Testen ist, dass selbst die QS in einer Hochverfügbarkeitsumgebung läuft, weil da viele Projekte parallel laufen und mal eben einen Index für knapp 200 Mio Datensätze anlegen oder drei Testtabellen ins System kippen und damit zig ( oder mehr ) Leute bis zur Behebung des Problems arbeitsunfähig machen, geht leider nicht.
In einer "eigenen" Umgebung solche Tests fahren, ist natürlich kein Problem. Aber da hat man eben nicht die Gewissheit, dass die Systemumgebung und die Datenkonstellation zu dem gleichen Ergebnis führen.

Viele Grüße
Tim

[mm1256]

Zitat von BlackbirdBerlin:

In einer "eigenen" Umgebung solche Tests fahren, ist natürlich kein Problem. Aber da hat man eben nicht die Gewissheit, dass die Systemumgebung und die Datenkonstellation zu dem gleichen Ergebnis führen.

Ich habe natürlich "eigene Umgebung" gemeint.

Bitte korrigiere mich, wenn ich da etwas falsch sehe:

Systemumgebung: Auch wenn die DB auf deinem eigenen Test-Server mit anderer Hardware läuft, sollten zuverlässige Ergebnisse möglich sein. Dass die Ergebnisse/Zeiten natürlich von der realen Umgebung beim Kunden abweichen, ist mir schon klar. Die Relation der Unterschiede untereinander dürfte jedoch eindeutig zu erkennen sein. Und darum geht es doch letzendlich. Wenn die Query-Zeiten ohne Index und mit Index z.B. im Verhältnis 10:3 wären, dann können die Unterschiede zur Systemumgebung des Kunden nicht ausschlaggebend sein. Denn ob es beim Kunden dann 10:5 oder 10:2 wäre, ist unerheblich. Die Steigerung wäre enorm. Etwas anders sieht es aus, wenn das Verhältnis nahezu gleich wäre. Aber auch dann hast du wenigstens einen Anhaltspunkt, was Sache ist.

Datenkonstellation: Wenn kein Join involviert ist...

Zitat von BlackbirdBerlin:

Es handelt sich um keinen Join sondern um eine einfache Tabelle, zu welcher bisher das für meinen Zugriff erforderliche Schlüsselfeld nicht indiziert ist.

...dürfte das auch kein Problem sein.

[jobo]

Zitat von mm1256:

..
Bitte korrigiere mich, wenn ich da etwas falsch sehe:

Systemumgebung: Auch wenn die DB auf deinem eigenen Test-Server mit anderer Hardware läuft, sollten zuverlässige Ergebnisse möglich sein. Dass die Ergebnisse/Zeiten natürlich von der realen Umgebung beim Kunden abweichen, ist mir schon klar. Die Relation der Unterschiede untereinander dürfte jedoch eindeutig zu erkennen sein. Und darum geht es doch letzendlich. ..

Ja, darum geht es primär und das kann man testen, auch in Relation.

Ich würde aber ergänzen:
Der springende Punkt bei solchen Systemen ist, dass sie idR einer Fülle von anderen Anforderungen- von OLTP bis ggF. Reporting- ausgesetzt sind, dass sie über Monate bis Jahre getuned und optimiert wurden und zwar bis in die Formulierung einzelner Abfragen hinein. Und das sehr wahrscheinlich zu einem guten Teil mit einem empirischen Vorgehen, sprich "nicht nachvollziehbar". Status Quo im Produktivsystem ist dann einfach, dass es eben läuft. Und das lässt man nicht gern fahren für einen blöden Index von einem Externen für einen Report, den kein einziger Manager braucht.
Das Risiko ist einfach, dass das System bei irgendwelchen zuvor harmlosen Abfragen kippt und steht.

Das bedeutet am Ende, die Änderung mag für sich Sinn machen und funktionieren und fürchterlich viel Speed bringen für die Abfrage. Wie aber reagiert der Rest des Systems? Das kann ich nur in einem Echtsystem feststellen in dem ein Arbeitstag, eine Arbeitswoche, ein Abschluss, etc pp durchgeorgelt wird.