Hi,
ich gestehe, ich habe nicht alles gelesen; aber da in Deiner Antwort auf Michaels Posting noch keine Klarheit herrscht, dürfte das Problem noch nicht gelöst sein ;-)
SELECT a.key
FROM a
LEFT JOIN b
ON a.key=b.key
WHERE(b.wert1 = 1234 AND b.wert2 < 4321)
Überlege Dir, wie Du gerne hättest, dass die Datenbank vorgeht. In diesem Fall willst Du alle Datensätze aus a, für die in den zugehörigen Datensätzen aus b etwas zutrifft - also musst Du zunächst die Ergebnisse aus b geschickt einschränken, bevor Du a involvieren lassen darfst.
Ich unterstelle mal, dass "b.wert1=1234" prozentual sehr selten in b ist; wenn ein gewisser Grenzwert überschritten ist, wäre ein Index darüber ansonsten sogar kontraproduktiv. Läuft der Index in b nun über wert1 und wert2 (in dieser Reihenfolge), wird die Ergebnismenge sehr schnell eingeschränkt und mit einem Range Scan für wert2 auf die Schnelle noch etwas reduziert. Anschließend würde MySQL die gefundenen Zeilen von b "besuchen" und ihren b.key auslesen. Wenn ich nicht irre, reagiert MySQL ähnlich wie Oracle, wenn Du dem Index noch key hinzufügst: dieser letzte Schritt entfällt. Ergo: Index in b über wert1, wert2, key.
Nachdem MySQL nun viele b.key ermittelt hat, muss es a nach dem jeweiligen key durchsuchen. Dazu bietet sich zwangsläufig ein Index in a über key an. Viel mehr bietet dieses Statement nicht, was optimiert werden könnte - überprüfe mit EXPLAIN SELECT ..., ob die DB so vorgeht, wie es gewünscht war.
Soweit ich das weiß sollten die Spalten in der Reihenfolge ihres "unique-Grades" im Index stehen.
Ja, es sollte so schnell wie möglich so viel wie möglich eingeschränkt werden. Ein mit key beginnender Index in b würde aber nichts bringen, weil key ja _vor_ dem Durchsuchen des Index noch nicht bekannt ist.
Wenn Du Dir einen mehrspaltigen Index als sortierten Baum vorstellst, wirst Du recht schnell dahinter kommen, wie die Datenbank vorgehen muss, um ihn zu durchsuchen. Mit dieser Erkenntnis ist die Findung des richtigen Index gar nicht mehr so schwer.
Cheatah
X-Will-Answer-Email: No