SQL Sauert zu lange

[nahpets]

Zitat von jobo:

Zitat von nahpets:

and SLAVE.ZusatzStatus in ('EZ','EV','EF','EA','EQ','EP')

Ich bin kein Firebird Spezialist, aber "in ()" oder "or" wird doch sehr wahrscheinlich intern gleich abgearbeitet? Wäre also nur besser für die Augen.

Das mag durchaus so sein, aber durch erhöhte Lesbarkeit hab' ich in der Vergangenheit schon des Öftern fachliche Fehler finden können, die ansonsten nicht auffielen. Gerade bei vielen and und or kann es schonmal schnell passieren, das eine Klammerung knapp daneben ging, auch wenn das Statement syntaktisch weiterhin korrekt war.
Und so knapp daneben liegende Klammern können schonmal schnell zu einer exorbitant steigenden Laufzeit führen.

Und letztlich resultieren meine Fragen zum "threadauslösenden" SQL ja auch daher.

[ibp]

Zitat von Dumpfbacke:

...
Wenn ich das ganze ohne die letzte Zeile mache mache dauert es ca. 2 Sekunden. Mit dieser Bedingung dauert es ca. 22 Sekunden.

Wie lange dauert es denn, wenn du die Abfrage nur mit der letzten Bedingung (Zeile) absendest?

SQL-Code:

from MASTER
Left Outer JOIN SLAVE on MASTER.Vorgangsnummer = SLAVE.Vorgangsnummer and (SLAVE.ZusatzStatus = 'EZ' or SLAVE.ZusatzStatus = 'EV' or
                                                                    SLAVE.ZusatzStatus = 'EF' or SLAVE.ZusatzStatus = 'EA' or
                                                                    SLAVE.ZusatzStatus = 'EQ' or SLAVE.ZusatzStatus = 'EP')
Left Outer Join MASTER UrMaster on MASTER.Vorgangursprung = UrMaster.Vorgangsnummer
where (UrMaster.referenznr = 'ABT_25' )

[nahpets]

Zitat von ibp:

Zitat von Dumpfbacke:

...
Wenn ich das ganze ohne die letzte Zeile mache mache dauert es ca. 2 Sekunden. Mit dieser Bedingung dauert es ca. 22 Sekunden.

Wie lange dauert es denn, wenn du die Abfrage nur mit der letzten Bedingung (Zeile) absendest?

SQL-Code:

from MASTER
Left Outer JOIN SLAVE on MASTER.Vorgangsnummer = SLAVE.Vorgangsnummer and (SLAVE.ZusatzStatus = 'EZ' or SLAVE.ZusatzStatus = 'EV' or
                                                                    SLAVE.ZusatzStatus = 'EF' or SLAVE.ZusatzStatus = 'EA' or
                                                                    SLAVE.ZusatzStatus = 'EQ' or SLAVE.ZusatzStatus = 'EP')
Left Outer Join MASTER UrMaster on MASTER.Vorgangursprung = UrMaster.Vorgangsnummer
where (UrMaster.referenznr = 'ABT_25' )

Das dürfte aber zu einem vollständig anderen Ergebnis führen, da die Abfrage auf die ReferenzNr ja nur ein Teil innerhalb der letzten AND-Bedingung ist. Diese Bedingung wird ja nur auf eine bereits erstellte Teilmenge angewandt und nicht auf die Ursprungstabelle. Von daher könnte ich mir vorstellen, dass dort die Nutzung des Index für die Datenbank nicht mehr möglich ist.

Eventuell könnte es aber hilfreich sein, im zweiten Left-Join grundsätzlich auf UrMaster.referenznr <> 'ABT_25' einzuschränken und in einem dritten Left-Join nur die Besonderheiten von UrMaster.referenznr = 'ABT_25' "abzuarbeiten".

[p80286]

Wenn man die Datenbank kennen würde, könnte man viel mehr dazu sagen. z.b. diese Slave.ZusatzStatus= or Slave.Zusatzstatus= Orgie, könnte die nicht durch Slave.ZusatzStatus<>x and Slave.Zusatzstatus<>y ersetzt werden?
U.U. kann man 'ABT_25' auch durch eine liste von IDs ersetzen (anderer Index)?
Und dieses

Code:

 SLAVE.SlaveStatus = 'In Arbeit' and SLAVE.Dzusatz is NULL) or
      (SLAVE.SlaveStatus = 'In Abreit' and SLAVE.Dzusatz = 'Gesperrt'

würde ich durch SLAVE.SlaveStatus = 'In Arbeit' and (SLAVE.Dzusatz is NULL or SLAVE.Dzusatz = 'Gesperrt') ersetzen.

Gruß
K-H

[Dumpfbacke]

Zitat von ibp:

Zitat von Dumpfbacke:

...
Wenn ich das ganze ohne die letzte Zeile mache mache dauert es ca. 2 Sekunden. Mit dieser Bedingung dauert es ca. 22 Sekunden.

Wie lange dauert es denn, wenn du die Abfrage nur mit der letzten Bedingung (Zeile) absendest?

[/CODE]

Das führt natürlich zum falschen Ergebnis. Es hat in Summe ganze 15 Minuten benötigt

[jobo]

Zu Ergebnis = 48 Stück.

Ich weiß nicht, wie der Optimizer von FB tickt. Aber ich würde versuchen, ihm zu helfen und folgende Strategie anwenden:
Die Kriterien, die die heftigste Einschränkung liefern für ein Kern-Select-Statement verwenden. (Das sind vielleicht bereits die bloßen Joins) Sodass ein grobes Ergebnis auf weniger als 5000 Datensätze kommt, darf auch weniger sein.
Auf dem Rest dann den ganzen Schnickschnack mit like '%' Or / in () usw. Mglw. geht das, wenn man das Kernselect klammert und außen dann die restlichen Kriterien abfragt.

So ungefähr (vorschlag):

Delphi-Quellcode:

select *
  from ( 
        select *
          from MASTER
          Left Outer JOIN SLAVE
            on MASTER.Vorgangsnummer = SLAVE.Vorgangsnummer
           and (SLAVE.ZusatzStatus = 'EZ' or SLAVE.ZusatzStatus = 'EV' or
               SLAVE.ZusatzStatus = 'EF' or SLAVE.ZusatzStatus = 'EA' or
               SLAVE.ZusatzStatus = 'EQ' or SLAVE.ZusatzStatus = 'EP')
          Left Outer Join MASTER UrMaster
            on MASTER.Vorgangursprung = UrMaster.Vorgangsnummer
         where MASTER.Status = 'In Bearbeitung'
           and SLAVE.SlaveNummerr is not NULL
           and ((SLAVE.SlaveStatus = 'Warten' or
               SLAVE.SlaveStatus = 'Unterbrochen' or
               SLAVE.SlaveStatus = 'In Arbeit' and SLAVE.Dzusatz is NULL) or
               (SLAVE.SlaveStatus = 'In Abreit' and
               SLAVE.Dzusatz = 'Gesperrt' and
               SLAVE.Sollende < Current_Date))
           and MASTER.FATW = 'Aktive'
       ) as Kernselect
 where ((    (Kernselect.AltesSystem like 'Start%' or Kernselect.AltesSystem like 'Vorgang%') 
         and  Kernselect.AltesSystem not like '%Abbruch%' 
         and  Kernselect.Storno is null
        ) 
       or 
        (Kernselect.referenznr = 'ABT_25')
       )

Wie man genau die Kriterien nach innen oder außen legt, muss anhand des Ausführungsplans oder Try/Error bestimmt werden. Ach und nochmal die Frage: Sind es wirklich alles Outer Joins oder vielleicht doch feste Joins? Ändert sich die Ergebnismenge, wenn Du feste Joins draus machst?