Grundsätzlich - kann DB mehrere Indizes kombinieren?

[hoika]

Hallo,
ein Join über 2 Tabellenfelder bei großen Tabellen sollte schneller sein, wenn beide Felder indiziert sind.
Das Bsp. von IBExpert zeigt das auch (ok, ist kein Join).
Mehrfelder-Indizes können z.B. bei Firebird nur benutzt werden, wenn die Abfrage die Felder in der Index-Reihenfolge benutzt: Index auf Tab1 (A,B) wird bei Where B=5 nicht benutzt.
Bei Oracle ist das aber glaube ich anders.

Bei vielen ist immer noch in Gedanken: Index verlangsamt Insert/Update, ist ja richtig.
Die Beschleunigung des Select steht im Hintergrund.

Es gibt doch bei Oracle auch einen Optimierer, der bei einer DB Vorschläge macht, wie die schneller arbeitet, also bei einer Query sagt, mit Index auf Feld X geht es schneller.
Ich meine jetzt nicht den internen SQL-Optimizer.

Ich hatte bei Interbase damals den IBPlanalyzer benutzt, um unseren Chef von Indizes zu überzeugen und auch mit realen Daten (große DB, Sekunden Ausführungszeit pro reale Funktion) gearbeitet.

Wenn eine Inventur oder Statistik am Wochenende gemacht wird und 10 Stunden dauert und es dem Kunden egal ist, kann man natürlich nicht so viel machen.


Heiko

[BlackbirdBerlin]

Hallo zusammen.
Vielen Dank für Euren Input.
Noch ganz kurz zur Erklärung, es handelt sich um eine verhältnismäßig zentrale Tabelle mit Bewegungsdaten, die permanent recht viele Schreibzugriffe (haupts. Insert) erfährt. In den Systemen, in welchen auf meinen Wunsch hin der Index angelegt wurde, ergab sich subjektiv keine Verschlechterung der Schreibperformance, jedoch eine massive Verbesserung des Lesezugriffs (s.o.).
Die QS-Systeme, auf denen man das jeweils aufgrund der Transportreihenfolge (SAP Dev, QS, Prod) prüfen kann, sind meist 1:1 Kopien vom Produktivsystem.
Die Software, die vom Index nutznießen würde, läuft täglich. Es handelt sich um ein Schnittstellenprogramm.
Die Datenbanken sind meist Oracle oder DB2.
Viele Grüße
Tim

[frankyboy1974]

hallo,

jetzt verstehe ich die Frage nicht mehr, welchen Sinn würde es machen mehrere Indizes (Wie lautet die Mehrzahl auf Index, ich musste erstmal google) auf eine Tabelle zu benutzen?

mfg

[mkinzler]

Wenn sich mehrere Spalten in der Einschränkung befinden (Name = "Mayer" und Vorname = "Peter"), dann ist es am optimalsten wenn ein Index über genau diese beiden Spalten existiert.
Je nach DBMS kann nun auch ein 2 Indizes (einer auf Name und einer auf Vorname) herangezogen werden, diese Lösung ist imho immer scghlechter als ein passender Index mit den beiden Spalten, aber besser als ein full table scan.

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

[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