Schlechte SQL Performance bei Join?

[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

[Pikachu]

Leg mal eine logische Datei für DBTEXT mit einem Zugriffspfad über die Spalten PDLFDN und PDBTDT an und probier dann mal mit ORDER BY PDLFDN, PDBTDT.

[schatte]

Leg mal eine logische Datei für DBTEXT mit einem Zugriffspfad über die Spalten PDLFDN und PDBTDT an und probier dann mal mit ORDER BY PDLFDN, PDBTDT.

Hallo Pikachu,

das geht dann flott. Aber es ist ja dann nicht mehr nach dem Datum (PDBTDT) sortiert.

@Holger: In der Datei DBTEXT sind 800.000 Sätze enthalten. Es enthält 5 Textspalten (PDTXT1 - 5 jeweils 50 Stellen lang), eine eindeutige laufende Nummer (PDLFDN), ein Datumsfeld (PDBTDT). Nun möchte ich die Textspalten per Freitextselektion durchsuchen. Damit ich nicht jeden Datensatz mit SQL UCASE(TEXT) Like '%SUCHBEGRIFF%' prüfen muss, lasse ich jeden Abend eine Wort Indexierung erstellen (Tabelle MATINDEX). Jedes Wort wird dabei in Großschrift in die Datei MATINDEX geschrieben mit einem Bezug auf die laufende Nummer (PDLFDN) der Datei DBTEXT.

Bisher hatte ich für die Abfrage ein Cobol Programm erstellt, was für den Suchbegriff jeweils die Sätze aus der MATINDEX liest und die dazugehörigen DBTEXT Datensätze in ein Sortfile einliest, damit nach PDBTDT sortiert werden kann.

Dieses Cobolprogramm wollte ich nun durch ein SQL Cobolprogramm ersetzen.


Gruß
Matthias