SELECT-Statement: Performance optimieren

[Bubble]

Hallo,

mal eine Frage zur Performance bei SELECT-Statements, die sowohl über mehrere Tabellen (per JOIN) gehen als auch zusätzliche Attributseinschränkungen in der WHERE-Klausel enthalten, also bspw. in der Art:



...
WHERE tabelle1.attribut1 = 5 -- Attributseinschränkung
AND tabelle1.attribut2 = tabelle2.attribut2 -- JOIN


Ist es von der Performance her besser, zunächst die JOIN-Bedingung zu formulieren oder zunächst die Einschränkung oder ist das egal?

Merci & viele Grüsse,
Bubble

[Pingu]

Hi,

also ich kann Dir jetzt nicht direkt dir Antwort geben.

Aber genau dafür gibt es den EXPLAIN (zumindest bei mySQL). Einfach das gewünschte Statement mit einem vorangestellten EXPLAIN aufrufen und schon gibt einem mySQL an über welche Zwischenresultate er zum Endresultat kommt.

Pingu

[Alex_K]

die anordnung der bedingungen in der where schleife sollten egal sein, bzw. davon habhängen wie der inhalt der DB aussieht, im idealfall sollte die bedingung durch die am meißten tupel wegfallen zuerst kommen.

ich würde die abfrage aber mit einem subselect machen:



...
from (select * from tabelle1 where tabelle1.attribut1 = 5) t1, tablelle2
where t1.attribut2 = tabelle2.attribut2


dadurch sollte die durch den join entstehende tabelle deutlich kleiner werden.

das ist jedoch alles nur theorie. in der praxis wird die DB diese anfragen versuchen zu optimieren, dadurch kann es sein dass es in der praxis auch keinen unterschied macht.

wie pingu schon sagte, am besten ansehen wie die DB diese operationen ausführt.

[fs111]

Das hängt natürlich auch immer davon ab, wo und wann man Indizes einsetzt, und ob die Datenbank eine Optimizer hat, oder nicht. Eine generellen Antwort ist da schwer zu geben.

fs111

[Christoph]

Dass ein JOIN assoziativ und kommutativ ist, weiß die Datenbank natürlich auch und sollte somit in der Lage sein, den besten Ausführungsplan zu finden. Dazu muss sie allerdings wissen wieviel Daten (und genaugenommen auch was für Daten) in den einzelnen Tabellen sind (bei PostgreSQL wird diese Statistik mit ANALYZE aufgebaut, es gibt auch irgendwo einen Dämon, der das automatisch bei Bedarf macht).

Mit einem Subselect umgeht man im allegmeinen den Optimizer, weil er sich dann nicht mehr den besten Plan aussuchen kann. Wenn die dabei entstehende temporäre Tabelle groß ist, dann ist das sehr ungünstig, weil auf der temporären Tabelle keine Indizes genutzt werden können.

[Bubble]

OK, vielen Dank euch erstmal für die Antworten.

In diesem speziellen Fall hier handelt es sich um eine Oracle-Datenbank, die betreffende Tabelle fasst derzeit ca. 5,3 Millionen Datensätze (von daher ist es durchaus interessant, die Abfragen zu optimieren).

Ich denke ich werde einfach mal testen ob sich an der Ausführungsgeschwindigkeit etwas ändert.

Viele Grüsse,
Bubble