Performance-Problem mit Subselects

[Jasocul]

In einer SQL-Abfrage habe ich 2 Subselects. In beiden greife ich auf die selbe Tabelle zu, nur die Bedingungen sind ein wenig anders.

Ich habe jetzt folgendes Phänomen:
Wenn beide Subselects in der Gesamtabfrage enthalten sind, dauert es ewig.
Nehme ich eins der Subselects raus, ist die Anwort in wenigen Sekunden da. Dabei ist es egal, welches der Subselects ich dafür nehme.

Ich greife in den Selects nur auf Tabellen zu (also keine Views, Functions, o.ä.).
Indexe werden gezogen, auch wenn bei einem Subselect ein Index Scan entsteht. Es gibt kein Table Scan.

Gibt es hier jemanden, der noch eine gute Idee Idee hat, wie ich das beheben kann?

Folgendes habe ich bereits versucht:

• union
• Ein einzelnes Subselect daraus machen mit "or"
• Mit "with" schon die Datenmenge beschränken
• Mit case arbeiten, damit je nach Bedingung nur eine Abfrage ausgelöst wird

In allen Fällen das selbe Ergebnis. Sobald beide Subselects in der Abfrage stehen, ist die Performance im Nirwana.

[mkinzler]

Wirklich Subselects oder Joins?

[Jasocul]

Ja, Subselects.
Eine Umstellung auf Joins habe ich noch nicht getestet.

[hoika]

Hallo,
ein SubSelect wird ja für jeden Datensatz der Hauptabfrage durchgeführt,
das kann halt dauern.

Ich würde was anderes Probieren (wie oben schon gesagt, Outer Joins z.B.)

[Bernhard Geyer]

Was sagt der Query-Analyser bezüglich Ausführungsplan dazu?

Wir hatten mal das Problem (bei MS SQL Server) da hier der Query-Analyser in einer Version Mist gebaut hat
und für relativ einfache Abfrage meinte mindestens 1 GB an RAM zu benötigen und eine riesige Ergebnisse zu haben.

[Jasocul]

Zitat:

Zitat von hoika (Beitrag 1489247)

Hallo,
ein SubSelect wird ja für jeden Datensatz der Hauptabfrage durchgeführt,
das kann halt dauern.

Ich würde was anderes Probieren (wie oben schon gesagt, Outer Joins z.B.)

Genauso ist es richtig.
Da habe ich wohl den Wald vor lauter Bäumen nicht mehr gesehen.
Die Abfragen hatte ich ja schon mit with in den Tests vorbereitet, aber dann einfach nicht daran gedacht, dass es dann mit einem Outer join ganz einfach umzubauen ist.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1489248)

Was sagt der Query-Analyser bezüglich Ausführungsplan dazu?

Wir hatten mal das Problem (bei MS SQL Server) da hier der Query-Analyser in einer Version Mist gebaut hat
und für relativ einfache Abfrage meinte mindestens 1 GB an RAM zu benötigen und eine riesige Ergebnisse zu haben.

Der hat mir nur den Hinweis auf auf den Index Scan geliefert.

Faszinierend finde ich es trotzdem, dass jedes Subselect alleine kein Problem verursacht und erst die gleichzeitige Nutzung die Performance einbrechen lässt.
Ich kann jetzt zwar das Problem beheben, aber die Ursache des Phänomens kenne ich immer noch nicht.

Vielen Dank für den richtigen Schubser

[Delphi.Narium]

Zitat:

Zitat von hoika (Beitrag 1489247)

Hallo,
ein SubSelect wird ja für jeden Datensatz der Hauptabfrage durchgeführt,
das kann halt dauern.

Ich würde was anderes Probieren (wie oben schon gesagt, Outer Joins z.B.)

Zitat:

Zitat von Jasocul

Faszinierend finde ich es trotzdem, dass jedes Subselect alleine kein Problem verursacht und erst die gleichzeitige Nutzung die Performance einbrechen lässt.
Ich kann jetzt zwar das Problem beheben, aber die Ursache des Phänomens kenne ich immer noch nicht.

Naja:

Man könnte in diesem Zusammenhang grob sagen:

Wenn ein Subselect schnell (10 ms) ist, aber für 1.000.000 Datensätze 1.000.000 mal schnell ausgeführt wird, so kann das dann insgesamt schon mal 'ne Weile dauern. -> 1.000.000 mal 10 ms -> ca. 2 Stunden und 45 Minuten.
Nur so als sehr grober Gedankengang, wenn man nach derartigen Performanzproblemen sucht.

Und nein: Das ist keine allgemeingültige Regel, sondern nur so ein Gedankenfetzen, den man im Hinterkopf behalten sollte.

[Jasocul]

Zitat:

Zitat von Delphi.Narium (Beitrag 1489254)

Man könnte in diesem Zusammenhang grob sagen:

Wenn ein Subselect schnell (10 ms) ist, aber für 1.000.000 Datensätze 1.000.000 mal schnell ausgeführt wird, so kann das dann insgesamt schon mal 'ne Weile dauern. -> 1.000.000 mal 10 ms -> ca. 2 Stunden und 45 Minuten.
Nur so als sehr grober Gedankengang, wenn man nach derartigen Performanzproblemen sucht.

Und nein: Das ist keine allgemeingültige Regel, sondern nur so ein Gedankenfetzen, den man im Hinterkopf behalten sollte.

Da sind wir völlig einer Meinung.

In diesem Fall muss aber noch ein anderes Problem vorliegen.
Ich habe hierbei folgende Laufzeiten erhalten (Test mit 1000 Datensätzen als Ergebnismenge):
Mit beiden Subselects gleichzeitig: ca. 1 Minute 10 Sekunden
Nur Subselect 1: ca. 0,7 Sekunden
Nur Subselect 2: ca. 1,1 Sekunden

Dass ich dann nicht davon ausgehen kann, dass es nur 1,8 Sekunden dauert, ist mir klar. Aber in diesem Fall ist das um den Faktor 60 langsamer.
Es ist auch nicht das erste SQL, das ich optimiere. Eigentlich laufen solche Sachen immer auf meinem Tisch auf, wenn die Kollegen nicht mehr weiterwissen. Daher ist es mir schon peinlich, dass ich auf die banale Lösung mit dem Join nicht gekommen bin.

Ich habe mir die bisherige Abfrage gespeichert. Vielleicht habe ich irgendwann mal Zeit, das genauer zu untersuchen.

[Delphi.Narium]

Zitat:

Zitat von Jasocul (Beitrag 1489273)

Eigentlich laufen solche Sachen immer auf meinem Tisch auf, wenn die Kollegen nicht mehr weiterwissen.

Oh, da bist Du aber nicht zu beneiden, den "Job" hatte ich auch mal ein paar Jahre, das ist nicht immer unbedingt spaßig, vor allem dann nicht, wenn man da gewaltige Laufzeitunterschiede herausarbeitet und das dann auch noch regelmäßig ;-)

Bezüglich SubSelect:

Mein Ansatz war immer:

Gibt es in einem Select ein Subselect dann lautet die erste Frage:

Wie bekomme ich das weg?

Nur wenn das nicht gelingt:

Wie bekomme ich das schneller?

[DasWolf]

Was für Unterabfragen sind das denn genau? Unterabfragen im SELECT- oder WHERE-Teil?
Beinhalten die Unterabfragen

Delphi-Quellcode:

a in (select a from...)

oder

Delphi-Quellcode:

exists(select 1 from...)

.