Schlechte SQL Performance bei Join?

[cbe]

Hallo allerseits!

... 2. Zweistufig arbeiten und im ersten Schritt ein Substrat ziehen (create table qtemp.ddd as (select ... from... !!! ohne order by!!!) und im zweiten Schritt select * from qtemp.ddd order by...)

hier stimme ich Dieter voll zu, das zweistufige Arbeiten hat mir auch schon deutlich Laufzeit gespart.
Ich mag allerdings dabei keine Objekte explizit erstellen, WITH ist mir sympatischer, und das geht auch mehrstufig:

with x as (
select IXFNAM, IXTEXT, IXRECL from matindex
where
      IXFNAM = 'DBTEXT'
  and IXTEXT =    'KUNDE'),
y as (SELECT
       'DBTEXT', PDPRN2, PDPRN3, PDKDK, PDMA, PDBTDT,
 rtrim(PDTXT1)||rtrim(PDTXT2)||rtrim(PDTXT3)||
 rtrim(PDTXT4)||rtrim(PDTXT5) as Txt
FROM DBTEXT right join x on IXRECL  = PDLFDN)
select  'DBTEXT', PDPRN2, PDPRN3, PDKDK, PDMA, PDBTDT, Txt
FROM y   order by pdbtdt

(Ich hoffe, die Syntax stimmt so...)

Hiermit erzwingt man, dass das Sortieren erst am Schluss gemacht wird, was manchmal sparsamer ist.
Würde mich interessieren, ob es hier auch hilft.

Ob der Right-Join hier Sinn macht usw. will ich gar nicht weiter ansprechen, das wurde ja schon diskutiert.

Gruß, Christian

[BenderD]

... frei nach Theorie zieht der Optimizer das gesamte SQL Statement zur Optimierung heran, arbeitet also nach dem Prinzip: entscheidend ist, was hinten rauskommt. Hier hält sich ein weiterer Mythos hartnäckig, das die Performance einer Abfrage von der geschickten Formulierung abhänge. Wenn sich der Optimizer von der Art der Formulierung der gleichen Abfrage (:= gleiches Ergebnis!) beeindrucken lässt, dann ist das ein Bug im Sinne von SQL (da zähle ich auch die Existenz zweier Query Engines dazu, die unter sich auswürfeln wer dran ist), oder ein Seiteneffekt des Nebenkriteriums des Optimizers: der nimmt das aktuell best bewerteteste Ergebnis, wenn ihm das gut genug ist, oder lange genug gesucht wurde.

Mehrstufigkeit wird also durch with Formulierungen nur zufällig erreicht, eine temporäre Tabelle erzwingt das. Ich bin kein Freund davon, aber damit kann man Teile mit hoher Selektivität (kleine Trefferzahl) vorziehen, um damit Abfragen zu beschleunigen.

Für die Ausgangslage, da könnte noch das parallel Database Feature weiterhelfen (nicht billig!), das verschiebt die Optimierung in die Richtung, die hier gebraucht wird.

D*B

Hallo allerseits!

hier stimme ich Dieter voll zu, das zweistufige Arbeiten hat mir auch schon deutlich Laufzeit gespart.
Ich mag allerdings dabei keine Objekte explizit erstellen, WITH ist mir sympatischer, und das geht auch mehrstufig:

with x as (
select IXFNAM, IXTEXT, IXRECL from matindex
where
      IXFNAM = 'DBTEXT'
  and IXTEXT =    'KUNDE'),
y as (SELECT
       'DBTEXT', PDPRN2, PDPRN3, PDKDK, PDMA, PDBTDT,
 rtrim(PDTXT1)||rtrim(PDTXT2)||rtrim(PDTXT3)||
 rtrim(PDTXT4)||rtrim(PDTXT5) as Txt
FROM DBTEXT right join x on IXRECL  = PDLFDN)
select  'DBTEXT', PDPRN2, PDPRN3, PDKDK, PDMA, PDBTDT, Txt
FROM y   order by pdbtdt

(Ich hoffe, die Syntax stimmt so...)

Hiermit erzwingt man, dass das Sortieren erst am Schluss gemacht wird, was manchmal sparsamer ist.
Würde mich interessieren, ob es hier auch hilft.

Ob der Right-Join hier Sinn macht usw. will ich gar nicht weiter ansprechen, das wurde ja schon diskutiert.

Gruß, Christian

[schatte]

(right oder left join ist hier verkehrt!!! das ist ein klassischer Fall für einen inner join).

Hallo,

ich habe das ganze nun auch mal auf einer 170er (220CPW) mit V5R2 getestet.
Beide Tabellen habe ich nun per SQL (CREATE TABLE) erstellt.
Erstellte Indexe:
MATINDEXI2: IXFNAM, IXTEXT, IXRECL
DBTEXTI1: PDBTDT (Empfohlen vom SQL Optimizer)

Nun frage ich einen Suchbegriff ab, der insgesamt nur aus 85 Zeilen besteht. Dies dauert beim INNER JOIN 46 Sekunden (eine Seite weiter blättern dauert 19 Sek!) und beim RIGHT JOIN nur 0,1 Sek (Blättern auch nur 0,0 Sek!).

Bei Abfrage eines Suchbegriffs, der insgesamt aus 38450 Zeilen besteht, ist das Ergebnis anders:
INNER JOIN: 0,2 Sek
RIGHT JOIN: 7,2 Sek (wobei das Blättern hier ebenfalls etwas flotter ist als beim INNER Join)

Muss ich also in meiner Indexierungsdatei erstmal abfragen wieviel Zeilen von der Abfrage betroffen sind und dann jeweils den RIGHT JOIN oder den INNEr JOIN verwenden? ;-)

Gruß
Matthias

[BenderD]

... das Problem ist die join order
- die Auswahlfelder sind in der Tabelle a
- die Sortierfelder sind in der Tabelle b
--bei großer Trefferzahl wäre es günstiger die Sortierung vorzuziehen
--bei kleiner Trefferzahl wäre es günstiger die Auswahl vorzuziehen

durch die Auswahl des Joins wird die Entscheidung des Optimizers nach a oder b beeinflusst!

Wenns um Anzeige geht, kann man das auch durch Optimize for 20 rows beeinflussen (BTW: das ist einer der Gründe, warum der Ooops Nerv und explain schrott ist!)

Hast du beide Konstellationen und beides soll schnell sein, erreichst du das auch durch Redundanz, sprich: Aufnahme der Sortierfelder in die MATINDEX (was bei schwacher Rechenleistung sicher das Beste ist)

D*B

Hallo,

ich habe das ganze nun auch mal auf einer 170er (220CPW) mit V5R2 getestet.
Beide Tabellen habe ich nun per SQL (CREATE TABLE) erstellt.
Erstellte Indexe:
MATINDEXI2: IXFNAM, IXTEXT, IXRECL
DBTEXTI1: PDBTDT (Empfohlen vom SQL Optimizer)

Nun frage ich einen Suchbegriff ab, der insgesamt nur aus 85 Zeilen besteht. Dies dauert beim INNER JOIN 46 Sekunden (eine Seite weiter blättern dauert 19 Sek!) und beim RIGHT JOIN nur 0,1 Sek (Blättern auch nur 0,0 Sek!).

Bei Abfrage eines Suchbegriffs, der insgesamt aus 38450 Zeilen besteht, ist das Ergebnis anders:
INNER JOIN: 0,2 Sek
RIGHT JOIN: 7,2 Sek (wobei das Blättern hier ebenfalls etwas flotter ist als beim INNER Join)

Muss ich also in meiner Indexierungsdatei erstmal abfragen wieviel Zeilen von der Abfrage betroffen sind und dann jeweils den RIGHT JOIN oder den INNEr JOIN verwenden? ;-)

Gruß
Matthias

[andreaspr@aon.at]

die Abfrage wird von der SQE durchgeführt laut Visual Explain und eure Indexvorschläge habe ich getestet.

Im Visual Explain wird das SQL auf mehrere Prozesse aufgelöst. Da kannst du dir auch gleich ansehen, welche(r) Prozess(e) so lange dauert.