nicht angemeldet
Hi Michael!
Erstmal vielen Dank für die ausführliche Erklährung, aber so 100%ig bin ich noch nicht da hinter gestiegen.
War das jetzt weil da so viele gleiche Ergebnisse drin sind?
Ganz im Gegenteil!
Je eindeutiger die Ergebnisse sind, desto besser der Effekt des Index.
Was meinst Du jetzt mit eindeutig? Wenn ich PLZ nehme ist das ja im Prinzip ein primärschlüssel, keine doppelten Einträge. Ist das jetzt extremst eindeutig? Aber das würde ich nicht verstehen, ob der DB jetzt in der Tabelle alle DS durchsucht, oder im Index, kann das so ein Unterschied sein?
Warum sollte man einen Index über die PLZ-Spalte erstellen, die
es jede PLZ eh nur einmal gibt? ich dachte das wäre dann
Schwachsinn?!
Genau das Gegenteil ist der Fall.
Also ist PLZ eindeutig, richtig?
...habe ich da was grundlegend falsch verstanden?
Ja. ;-)
:-)))
Ein Zugriff über den Index kostet durchaus auch Rechenzeit - aber
sehr viel weniger, als _sämtliche_ Datensätze zu prüfen.
Wenn Du aber diese Rechenzeit bezahlen mußt, dann willst Du als
Ergebnis möglichst bereits den _exakten_ Treffer haben.
Wenn Dir der Zugriff auf den Indexbaum von 1.5 Millionen Datensätze
noch 100000 Treffer zurück liefert, von denen Du dann über weitere
WHERE-Klauseln fast alle wieder wegwerfen mußt, dann hat der Index
Deine Anforderung nur zum Teil beschleunigt.
Ah, jetzt verstejhe ich doch "eindeutig, d.h. möglichst wenige DS zurückgeben, was?
Zum Hintergrund, eine normale Abfrage sieht so aus:
SELECT
objekte.ort
FROM orte
LEFT JOIN objekte
ON orte.plz=objekte.plz
WHERE orte.Land='$bundesland'
Was würdet Ihr hierfür für Indices empfehlen?
a) Ein Index über das Paar ("plz", "land") in der Tabelle "orte"
b) Ein Index über "plz" in der Tabelle "objekte"
Was die Reihenfolge des Paares angeht, müßte ich wissen, welche der
beiden Spalten eindeutigere Treffer liefert - diese sollte innerhalb
dieses Paares vorne sein.
Also PLZ - natürlich gibt es mehr PLZ als Bundesländer :-)
Es reicht allerdings nicht, eine beliebige Abfrage auszuwählen, um
daraus die optimale Struktur der Indexe zu bestimmen - Du mußt viel-
mehr _alle_ möglichen Abfragen kennen und am besten auch noch die
Wahrscheinlichkeit für deren Auftreten.
Wenn Du dann die Kosten für die Ausführung jedes einzelnen Statements
plus deren Wahrscheinlichkeit kennst, kannst Du die Gesamtkosten für
alle Abfragen berechnen. Und _das_ ist die Größe, die Du wahrschein-
lich optimieren willst! Denn von ihr hängt die Last auf Deinem Server
ab. Es kann durchaus sein, daß Du ein einzelnes Statement langsamer
machst, weil ein anderes, wahrscheinlicheres Statement dabei sehr viel
schneller wird.
Ja, es gibt bestimmte Abfragen, die sehr häufig kommen, und die obige ist die heufigste. Alle anderen sind unwichtig.
ich glaube, so langsam verstehe ich es. Dann kann ich mich ja mal an eine andere Tabelle wagen:
Die BLZ wie oben beschrieben, und da ist die Suche sehr viel komplizierter. Und zwar geht es darum, eine Kombination aus BLZ und Bankname auf Plausibilität zu überprüfen.
Die Abfrage sieht etwas so aus:
SELECT * FROM blz
WHERE BLZ='$blz'
AND (Ort Like '%$begriff_1%'
OR Ort Like '%$begriff_2%'
OR Bezeichnung Like '%$begriff_1%'
OR Bezeichnung Like '%$begriff_2%')
Nach dem Schema will ich einen vom Benutzer eingegebene Wert auf Plausibilität überbrüfen, aber ich weiß genau das das so nicht gut ist:-)
Ich denke hier sollte ich einen Index über 'BLZ,Ort,Bezeichnung' erstellen, oder? Oder sollte ich hier lieber mit Fulltext arbeiten? Mein Problem ist halt, das der USer wahrscheinlich sowas wie 'SPK Wuppertal' eingibt, oder 'Sparkasse W' oder was da alles möglich ist, und in einem gewissen Rahmen sollen diese Sachen erkannt werden, daher spalte ich den String "SPK Wuppertal" beim Leerzeichen auf und durchsuche die 2 Spalten einzelnd nach allen Begriffen.
Was sagst Du dazu? Wie könnte man das optimieren?
jedenfalls nochmal vielen Dank für Deine Hilfe bisher, so langsam lichtet sich der Schleier...
Viele Grüße
Andreas