JOIN dauert mehrere Minuten (Problem: fehlende FKs ?)

[Sven Rautenberg]

Moin!

Wenn ich folgenden Befehl ausführe:

Sehr gut!

EXPLAIN SELECT *
FROM ort, name
WHERE ort.key = name.key
AND name.value = 'Mustermann';

dann führt das zu folgender Ausgabe:
id   select_type   table   type  possible_keys   key           key_len   ref             rows     Extra
1    SIMPLE        ort     ALL   fk_ort_keys     NULL          NULL      NULL           2907694
1    SIMPLE        name    ref   fk_name_keys    fk_name_keys  38        testdb.ort.key  10      Using where

Allerdings werde ich daraus auch nicht schlau. Kann mir jemand das erklären?

Das Handbuch bietet folgende Seite: http://dev.mysql.com/doc/refman/5.1/de/explain.html

Was sehen wir also? Die erste Zeile zeigt an, was aus der Tabelle "ort" an Indices benutzt werden kann. Wir sehen: type = ALL, und die Handbuchseite sagt dazu: "ganz schlimm", weil das ein Full-Table-Scan ist. Hier verschenkst du also mächtig Performance.

Das Problem, Ilja hat es schon angesprochen, ist unter anderem deine Schreibweise des Joins. Ändere das. Das erleichtern der Datenbank und auch dir dann, die Zusammenhänge zwischen "Bedingung zur Zuordnung des Joins" zu trennen von "Bedingung zur Aussiebung der gewünschten Daten".

Zweitens: Du hast die Verknüpfung der beiden Tabellen "ort" und "name" über die jeweilige Spalte "key". Das schreit förmlich danach, diese Spalte als Index anzulegen. Die Frage ist, ob die Spalte schon in irgendeiner Tabelle ein Index (z.B. primärer Index) ist. Wenn ja, dann wäre die andere Spalte noch als einfacher Index hinzuzufügen, wobei darauf zu achten ist, dass die Datentypen der beiden Tabellen identisch ist. Also nicht einmal BIGINT, einmal TINYINT nehmen, sondern das Gleiche! Im Zweifel den Datentyp mit dem größeren Wertebereich.

Irgendwelche Indices hast du offenbar schon angelegt, sonst würde in der Spalte "possible_keys" nicht "fk_ort_keys" und "fk_name_keys" erscheinen. Die Frage wäre, was das für Indices sein sollen. Vermutlich sind sie derzeit einfach überflüssig, zumindest fk_ort_keys, aber das hängt von den anderen Abfragen ab, die du sonst noch so ausführst.

Sollte ich vielleicht noch die Tabelle KEYS in die Abfrage mit einbinden?

Diese Tabelle taucht in deiner Abfrage bislang absolut nicht auf, also warum sollte sie hinzugefügt werden?

- Sven Rautenberg