Versuchen wir ein Beispiel und sei dazu folgende Tabelle gegeben:
Kundennummer, Postleitzahl, Ort, Rufnummer, eMail
Code:
Select * from tabelle where kundennummer = 1
Ein Index auf Kundennummer wäre hier sinnvoll.
Code:
Select * from tabelle where Ort = "Bärlin"
Ein Index auf Ort wäre hier sinnvoll.
Code:
Select * from tabelle where Kundennummer = 1 and Ort = "Bärlin"
Ein Index auf die Kombination aus Kundennummer und Ort wäre hier sinnvoll.
Der Kunde sagt aber: Ein Index auf Kundennummer und ein Index auf Ort reichen aus.
Hier im Beispiel hätten wir (im Kundenidealfall) auf jede der Spalten einen Index. Bei Abfragen, die über beliebige Kombinationen der Spalten gehen, soll gefälligst die Datenbank schauen, welcher Index bzw. welche Kombination aus 1:n Indizes hier die richtige ist.
frankyboy1974 macht dazu einen Vorschlag in der Art:
Code:
select * from (
select * from tabelle where kundennummer = 1
) where Ort = "Bärlin"
Wenn die Datenbank "klug" ist, nutzt sie für die innere Abfrage den Index auf Kundennummer, aber ob sie für die so gefundene Teilmenge noch den Index auf die Spalte Ort der Tabelle nutzen kann, wage ich zu bezweifeln. Bei der äußeren Abfrage macht sie eher ein Full-Table-Scan, und wenn das Ergebnis komplett im Speicher liegt, geht das sicherlich sehr schnell. Ist die Datenmenge aber riesig (ein paar Millionen Sätze) so muss sie da wohl eher im Temp-Table-Space "rumwühlen".
Aber: Die Erfahrung, dass derartige Konstrukte deutlich performanter sind, als eine "innere" Abfrage, die alles abfackelt, habe ich schon mehr als nur einmal gemacht. Es kommt hier wohl wieder auf das Datenbanksystem und ein bisserl Versuch und Irrtum an.
Zumindest bei Oracle haben wir uns regelmäßig die Ausführungspläne angeschaut und ggfls. einen neuen Index angelegt, der für die Abfrage sinnvoller zu nutzen war, als das, was die Datenbank mit den vorhandenen Indizes machen konnte. Sehr vereinzelt kam es auch vor, dass die Datenbank nicht den bestmöglichen Index genutzt hat, dann wurde das
SQL-Statement mit einem entsprechenden Hint versehen.
Bei Oracle müsste man aber doch eigentlich aus den Ausführungsplänen der Abfragen entnehmen können, ob der Kunde mit seiner Aussage recht hat oder eben auch nicht.
@BlackbirdBerlin
Hast Du beim Kundensystem irgendwie die Möglichkeit, für alle Abfragen an die Ausführungspläne zu kommen und sie dahingehend zu überprüfen, ob die Aussage des Kunden (zumindest in einem Fall) zutreffend sein könnte?
Da es sich hier ja eher um eine akademische Diskussion, die sich hauptsächlich um die Theorie dreht (und ggfls. die Fakten außen vor lässt), handelt, kannst Du die Kundenbehauptung vermutlich nur durch handfeste Fakten widerlegen.
Zitat von
frankyboy1974:
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.
Die Frage hier ist aber doch gerade: kann die Datenbank
"dann kombiniert die DB einfach die beide Inizes" das?
Sorry, wenn ich das jetzt mal überspitzt umformuliere:
Zitat von
frankyboy1974:
Also mein Gedanke wäre immer noch, bei der ersten Abfrage veruchst du einen Index zu erwischen, und den Rest programmierst du selbst.
Wenn die Datenbank so schlecht ist, programmiere doch selber eine.
Das halte ich für eine sehr schlechte Alternative. Warum nicht die Fähigkeiten der Datenbank vollumfänglich ausnutzen, sondern nur, weil der Kunde irgendwelche Restriktionen einführt, die die Leistungsfähigkeit der Datenbank einschränken, irgendwas drumherum programmieren?
Zitat von
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.
Update und Delete machen eine
DB bei der Pflege der Daten sicherlich langsamer, durch die Indexpflege. Aber der zu pflegende Index sorgt auch dafür, dass die zu ändernden oder zu löschenden Daten schneller gefunden werden, als durch einen Full-Table-Scan.
Es wäre jetzt also der Beweis zu erbringen, was aufwändiger ist: Die zusätzliche Pflege oder die Suche der zu ändernden/löschenden Datensätze ohne Index.
Zitat von
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.
Ein Index oder eine Indexkombination über mehrere Felder ist natürlich nur für solche Felder sinnvoll, auf die häufig zur Datenauswahl zugegriffen wird.
Die unterschiedliche Reihenfolge identischer Spalten in mehrere Indizes kann dagegen durchaus sinnvoll sein. Nicht nur für die Auswahl einer zu selektierenden Teilmenge, sondern auch für deren sortierte Ausgabe in der im Index enthaltenen Reihenfolge.
Selbst bei einer uneingeschränkten Ausgabe aller Daten in der im Index festgelegten Reihenfolge, kann dies zu deutlichen Laufzeitverkürzungen führen.
Der letzte Satz von Sir Rufos Aussage ist sehr wesentlich, es ist ein Balance-Akt, der hier aber vom Kunden durch Vorgaben ggfls. sehr starkt behindert werden kann.
Wenn der optimale Index für eine große, immer wiederkehrende Abfrage ein Index aus einer Spaltenkombination ist, so wird hier durch die Einschränkung
ein Index = eine Spalte, die Möglichkeit des Ausbalanzierens doch deutlich eingeschränkt.
[
OT]die Steigerung von
optimal, optimaler, am Optimalsten nutzen wir eigentlich nur, wenn irgendetwas so richtig Sch.....adedaskeinsalzdranwar ist.[/
OT]