Wie bekomme ich einen JOIN schnell?

[Michael Schröpl]

Hi Andreas,

Wobei - mysql erstellt pro Tabelle ein Verzeichis, wo sollte dann der Index gespeichert werden?

weder glaube ich diese Behauptung, noch macht sie überhaupt Sinn: Nicht mySQL erstellt diese Dateien, sondern der jeweilige Tabellentreiber. Und da kann jeder machen, was er will.

Aber es kann doch pro Abfrage nur _ein_ Index verwendet werden, oder?

Pro Abfrage auf _eine_ Tabelle, ja. Aber ein JOIN enthält Abfragen auf mehrere Tabellen.

Wenn ein JOIN versuchen soll, die zueinander passenden Werte aus (mindestens) zwei Tabellen zu finden, dann hat er verschiedene Möglichkeiten. Zwei fallen mir spontan ein:

1. In beiden Tabellen ist das Berechnen der Werte "schwierig". Dann ist es sinnvoll, beides separat zu berechnen, beide Ergebnismengen zwischenzuspeichern und sie anschließend zu kombinieren. Dies impliziert, beide Mengen nach dem JOIN-Kriterium zu sortieren - und das ist bekanntlich teuer (n * log(n)). Läge bereits ein Index, also ein nach dem Auslese-Kriterium sortierter Baum vor, dann könnte man diesen eventuell nutzen - selbst wenn das JOIN-Kriterium selbst gar nicht Bestandteil der WHERE-Klausel dieses Tabellenzugriffs ist: Es könnte trotzdem die beste verfügbare Methode sein, die Tabelle in dieser Reihenfolge zu traversieren.

2. Das Finden eines zugehörigen Wertes ist in einer der beiden Tabellen sehr viel einfacher als in der anderen (beispielsweise weil in der einen Tabelle ein UNIQUE INDEX darauf existiert). In diesem Falle weiß der Query Optimizer, daß die Anzahl der Treffer im Wesentlichen durch die Treffer aus der anderen Tabelle bestimmt wird, und er weiß, daß er zu jedem dieser Treffer sehr schnell über den Indexzugriff das passende Gegenstück finden kann. In diesem Fall kann der Query Optimizer sich dafür entscheiden, nicht die beiden Mengen getrennt zu berechnen, sondern nur die zweite und über diese eine Schleife laufen zu lassen, in der jeweils das passende Gegenstück geholt wird. Dies ist insbesondere dann sinnvoll, wenn die Ergebnismenge dann später _nicht_ nach dem JOIN-Kriterium sortiert ausgegeben werden soll - wäre dies der Fall, dann hätten wir nicht viel gewonnen, wenn wir die zunächst nicht notwendige Sortierung später dann doch noch durchführen müßten (mit einer anderen Anzahl von Datensätzen - meistens kleiner, in manchen JOIN-Fällen aber sogar größer).

Viele Grüße
      Michael

P.S.: Indexe über Spalten aus mehreren Tabellen sind in SQL so ohne weiteres nicht darstellbar, fürchte ich.
Andererseits habe ich in Oracle 7 Mitte der 90er mal ein Konstrukt verwendet, welches sich "Cluster" schimpfte und einen gemeinsamen Cluster-Index definierte - in ein solches Cluster konnte man dann mehrere Tabellen so legen (d. h. darin erzeugen und definieren, welche Spalte[n] für den Cluster-Index verwendet werden sollten), daß die Datensätze in bereits nach dem Cluster-Index geJOINter Form physikalisch abgespeichert wurden. Das war natürlich für das Auslesen in der geJOINten Form sehr angenehm, weil es die Anzahl der Festplattenzugriffe erheblich reduzierte.