Outer-Joins extrem langsam =(

[Deep-Sea]

Hallöchen,
ich such jetzt schon seit gestern Mittag nach einer Antwort:

Bei einem INNER JOIN dauert die Abfrage mit zwei Test-Tabellen von einmal 1000 und einmal 999 Einträgen so gut wie nichts, jedoch braucht ein LEFT JOIN ganze 12 Sekunden! ò.Ó Da stimmt ya wohl was nicht ...
Irgendwie weiß ich nicht mehr weiter ...

PS: Kann FB nicht so etwas wie INTERSECT oder EXCEPT? ...

[Markus Kinzler]

Outer Joins sind immer gefährlich. Ohne die Struktur der Datenbank und die Abfrage zu kennen, kann man aber nichts Genaueres sagen.
Gibt es passende Indexe?

PS: Kann FB nicht so etwas wie INTERSECT

Momentan nicht.

oder EXCEPT?

 not in ( ...

[Deep-Sea]

[QUOTE=Markus Kinzler;148561]Outer Joins sind immer gefährlich. Ohne die Struktur der Datenbank und die Abfrage zu kennen, kann man aber nichts Genaueres sagen.
Gibt es passende Indexe?

Gefährlich? Wieso? ^^

Tabelle A: ID (Primary Key mit Index) - Viele, hierfür nicht wichtige Felder
Tabelle B: ID (Primary Key mit Index) - ID_A (Fremdschlüssel von Tabelle A) - ID_X (Fremdschlüssel von Tabelle X, ist hierfür aber auch unwichtig)

B ist also eine Beziehungstabelle zwischen A und X. Ich will nun eigentlich alle Datensätze aus A, auf die kein Eintrag aus B verweist.

SELECT A.ID, [...]
FROM A
LEFT JOIN B ON B.A_ID = A.ID
WHERE (B.A_ID IS NULL);

Ich denke, die Lösung ist eigentlich ganz ok, oder?!


Was mich ja auch verwundert, dass ein INNER JOIN, was in meinem Test nur 1 Datensatz weniger ausgibt, in "Null Zeit" abläuft und das LEFT JOIN ... nunja ...

[Markus Kinzler]

Mit gefährlich meinte ich in Bezug auf die Geschwindigkeit.

SELECT A.ID, [...]
FROM A
where A.ID not in (SELECT B.A_ID from B);

[Deep-Sea]

Mit gefährlich meinte ich in Bezug auf die Geschwindigkeit.

SELECT A.ID, [...]
FROM A
where A.ID not in (SELECT B.A_ID from B);

Diese Abfrage ist nur bei wenigen Daten schneller - hab es gestern schon getestet.
Mit LEFT JOIN wie gesagt 12s bei 1000 Datensätzen und 30s bei 2000.
Mit NOT IN bei 1000 Datensätzen zwar nur 0,5s, aber es steigt extrem an, so hat er bei 2000 Datensätzen schon 2,5s. Im aktuellen Realfall braucht sie zwar nur halb so lange wie mit LEFT JOIN, aber trotzdem zu lange.

[Markus Kinzler]

Welche FB Version setzt du ein?

[Deep-Sea]

Ok, Problem gelöst.
Ich hab einen Sekundärindex hinzugefügt und schon gehts ... find ich aber trotzdem komisch, selbst wenn er die IDs live sortieren müsste, würde das "nichts" dauern (sortiere ja manuell auch 1 Million Integer mittels MergeSort in einer Sekunde ... also nix von wegen 1000 Datensätze und 12 Sekunden ... mhh naaaaja, egal)

[Thomas Steinmaurer]

Hi,

bei so einer Anfrage wie von Dir, braucht man immer die vollständige DDL der Tabelle inkl. Indizes, das tatsächlich ausgeführte Statement, den erzeugten Zugriffsplan und die eingesetzte Firebird-Version.

Ansonsten muss man sich wieder dem Firebird-Orakel bemühen, um helfen zu können. ;-)

Vielleicht waren in deinem Fall einfach die Indizes Out-Of-Date, d.h. Selektivität hat nicht gepaßt, usw ... Ein Sekundärindex würde bedeuten, dass ein neuer Index mit aktueller Selektivität, ... angelegt wird.

Thomas