SQL Performance

[mariupol1963]

Hallo,

eine kleine Frage.

Was ist schneller

SELECT FELD_A,
(SELECT FELD_B FROM DATEI_B WHERE …)
FROM DATEI_A

Oder

SELECT FELD_A, FELD_B
FROM DATEI_A
LEFT OUTER JOIN DATEI_B

[Fuerchau]

Das hängt ganz davon ab, da die Ergebnisse unterschiedlich sein können.
Beim skalaren Subselect darf nur 1 Satz und 1 Feld als Ergebnis rauskommen.
Beim Join darfs es eben auch 1:N-Beziehungen geben.

Wenn Zugriffspfade vorhanden sind, gibt es eigentlich keinen Unterschied.

[mariupol1963]

Es geht um 1:1 oder 1:0.
DATEI_B beinhaltet die Summen (SQL-View).

[Fuerchau]

In diesem speziellen Fall kann man Performancevorteile bekommen, wenn man die Summe nicht über die View ermittelt.

Begründung:
Die View enthält keine Schlüssel und muss ggf. komplett als temporäre Tabelle erstellt werden um anschließend eine Joinbeziehung aufzubauen.

select sum(feld) from file where key=irgendwas

ist immer schneller als

with
myView as (select key, sum(feld) as feld from file group by key)
select feld from myview where key=mykey

Aber auch da kann der Optimizer ein Schnippchen schlagen.
Bei einem Select ohne where (also eigentlich alles) kann die View wieder schneller sein.

Oder wie es hier auch heißt:

it depends .....

[mariupol1963]

Danke.
Werde ich testen.

[BenderD]

Hallo,

frei nach (SQL) Theorie zählt die Ergebnismenge und falls diese gleich ist, sollte das gleich schnell sein. Alles andere sind Dreckeffekte des Analyzers und des Optimizers, die nicht nur mit jedem PTF in die andere Richtung kippen können, sondern auch von Fall zu Fall differieren könnten.

mfg

Dieter Bender

Hallo,

eine kleine Frage.

Was ist schneller

SELECT FELD_A,
(SELECT FELD_B FROM DATEI_B WHERE …)
FROM DATEI_A

Oder

SELECT FELD_A, FELD_B
FROM DATEI_A
LEFT OUTER JOIN DATEI_B

[mariupol1963]

Das stimmt.
Ung. gleiche Antwortzeiten

[Fuerchau]

So ist das nun mal mit den Zeiten.
Es zeigt sich immer wieder, dass Anwendungen mit geringer Satzanzahl entwickelt und getestet werden.
Da waren die Antwortzeiten sogar sehr schnell, obwohl die Tabellen keinerlei Indexe enthielten.

Nachdem die Anwendung nun ein paar Wochen läuft, und inzwischen mehrere 10.000 Datensätze erzeugt wurden, zeigt sich die Schwäche im Design.

Deshalb:
Die Aussagen, was ist schneller oder nicht, hängt auch im Wesentlichen von der Satzanzahl und den verfügbaren Zugriffswegen ab.
Obige Abfrage mit ca. 10.000 Sätzen bei V5R1 brachte ungefähr gleiche Zeiten.
Die selbe Abfrage mit ca. 1.500.000 Sätzen bei V5R3 brachte gravierende Unterschiede. Der beste Zugriff war dort mit dem integrierten skalaren Subselect anstelle der View.

[BenderD]

Hallo,

das ist aber gerade so ein Schmutzeffekt, wie er eigentlich nicht sein sollte. Die alte Query Engine hat offenbar erkannt, dass die View in einen Subselect auflösbar ist und die aktuelle (Beta) Version der viel gepriesenen neuen Query Engine merkt das nicht und berechnet bei Verwendung der View einen suboptimalen Zugriffsplan.

mfg

Dieter Bender

So ist das nun mal mit den Zeiten.
Es zeigt sich immer wieder, dass Anwendungen mit geringer Satzanzahl entwickelt und getestet werden.
Da waren die Antwortzeiten sogar sehr schnell, obwohl die Tabellen keinerlei Indexe enthielten.

Nachdem die Anwendung nun ein paar Wochen läuft, und inzwischen mehrere 10.000 Datensätze erzeugt wurden, zeigt sich die Schwäche im Design.

Deshalb:
Die Aussagen, was ist schneller oder nicht, hängt auch im Wesentlichen von der Satzanzahl und den verfügbaren Zugriffswegen ab.
Obige Abfrage mit ca. 10.000 Sätzen bei V5R1 brachte ungefähr gleiche Zeiten.
Die selbe Abfrage mit ca. 1.500.000 Sätzen bei V5R3 brachte gravierende Unterschiede. Der beste Zugriff war dort mit dem integrierten skalaren Subselect anstelle der View.

[mariupol1963]

Ich habe mit den echten Dateien getestet - ca. 300.000 Sätze.
Die Version mit subselect war ein Tik schneller, aber nicht grossartig.