Hallo Leute,
ich habe hier eine Frage zur benötigten Zeit für eine Abfrage. Es wird in der Where Abfrage zwei Felder abgefragt, auf beiden Feldern liegt jewals ein extra Index.

Fall 1
Where Feld1 = '4EE' and Feld2 = 'Frankfurt'
Fall 2
Where Feld1 = '4EE' and (Feld2 = 'Frankfurt' or Feld2 = 'München'

Nun zu meiner Frage.Warum dauert es denn bei dem zweiten Fall erheblich länger als bei den ersten Fall ? Ich habe es mit IBExpert überprüft und dort ist es genau so.

Wie kann denn so etwas sein und wie kann ich es denn Ändern ?

Tanja

Weil für die zweite Abfrage kein passender Index verfügbar ist

Erstelle dir einen Index der beide Felder beinhaltet, dann sollte das fixer gehen

Die frage ist doch: Wieso dauert es wesentlich länger, wenn man auf dem nicht indizierten Feld2 auf zwei Werte statt auf einen Wert prüft? Gegenfrage:
Ist ein Unterschied zwischen

markieren

Code:

where Feld1='Foobar' and (Feld2 = 'Frankfurt' or Feld2='München')

und

markieren

Code:

where Feld1='Foobar' and Feld2 in ('Frankfurt','München')

Ich vermute, beides ist gleich langsam.

Falls das wirklich wesentlich langsamer ist als

markieren

Code:

where Feld1='Foobar' and Feld2='Frankfurt'

, ist das ein Bug in FB bzw. eine Schlamperei.

In MySQL/Postgres gibt es sowas wie EXPLAIN ANALYSE SELECT * FROM xyz WHERE ... .

Gibt es das in Firebird auch?
Dann siehst du ja wie/ob welcher Index verwendet wird.

Zitat von Sir Rufo:

Weil für die zweite Abfrage kein passender Index verfügbar ist
Erstelle dir einen Index der beide Felder beinhaltet, dann sollte das fixer gehen

nein, Firebird kombiniert in einem SQL pro Tabelle auch mehrere Einzelindizes, wenn das sinnvoll
erscheint. Die beiden Einzelindizes sind also durchaus korrekt.

Über welche Zeitunterschiede und welche Datenmengen reden wir denn eigentlich.

Der IN Operator ist nicht schneller als die die OR Implementation, das sieht man am Plan, der für beide
Varainten meistens identisch ist.

Wenn solche Abfragen bei dir Standard sind, dann kann es ggf sogar sinnvoll sein, das du auf
Feld 2 gar keinen Index hast, dann muß Firebird in der Ergebnismenge auf Feld1 einen Tablescan
machen. Solche Probleme treten aber erst bei sehr großen Datenmengen wirklich relevant auf.

Zitat von IBExpert:

nein, Firebird kombiniert in einem SQL pro Tabelle auch mehrere Einzelindizes, wenn das sinnvoll
erscheint. Die beiden Einzelindizes sind also durchaus korrekt.

Über welche Zeitunterschiede und welche Datenmengen reden wir denn eigentlich.

Der IN Operator ist nicht schneller als die die OR Implementation, das sieht man am Plan, der für beide
Varainten meistens identisch ist.

Wenn solche Abfragen bei dir Standard sind, dann kann es ggf sogar sinnvoll sein, das du auf
Feld 2 gar keinen Index hast, dann muß Firebird in der Ergebnismenge auf Feld1 einen Tablescan
machen. Solche Probleme treten aber erst bei sehr großen Datenmengen wirklich relevant auf.

Die Datenmenge ist leider etwas größer. Das Ergebnis beinhaltet 19 Treffer und die Tabelle enhält leider 192585 Datensätze.

EIn in geht auch nicht schneller dieses habe ich bereits geprüft. Das ein Or jeodch so lange dauert hätte ich nicht erwartet.

Tanja

Also unter 200k Sätze ist ja nicht wirklich groß. Ist das die komplette Query oder nur der "Kern"? Hängen da in der Realität noch Joins dran? Und von welchen Laufzeiten (in ms) sprechen wir hier? Wird das einmalig oder in einer Schleife aufgerufen?

Zitat von Union:

Also unter 200k Sätze ist ja nicht wirklich groß. Ist das die komplette Query oder nur der "Kern"? Hängen da in der Realität noch Joins dran? Und von welchen Laufzeiten (in ms) sprechen wir hier? Wird das einmalig oder in einer Schleife aufgerufen?

Leider hast du hier recht. Ich war mir sicher das ich die Join auskomentiert hatte und es wurde nicht schneller. Es kommt also von dem leider sehr komplexen Join. Oh man ab und zu steht man einfach auf dem Schlauch und sucht am falschen Ende.

Ich versuchen hier mal alles Darzustellen:

Tabelle 1:

markieren

Delphi-Quellcode:

Feld1 VarChar(3)
Feld2 VarChar(40)
Feld3 VarChar(40)
BNummer VarChar(12)
und noch viele weitere Felder

Es ist auf jedem Feld von oben ein Index

Tabelle2:

markieren

Delphi-Quellcode:

AAZaehler Numeric (9,0)
AAStatus CarChar(13)
BNummer VarChar(12)
Kriterium VarChar(35)
und noch viele weitere Felder

Es ist auf jedem Feld ein Index und auf dem AAZaehler noch ein DESC Index wegen dem Maxwert

So sieht nun mein Select Aus

markieren

Delphi-Quellcode:

....
From Tebelle1
Left Outer join Tabelle2 on (Tabelle1.BNummer = Tabelle2.BNummer and
                            Tabelle2.aazaehler = (Select Max(AAZaehler) from Tabelle2 AA where AA.BNummer = Tabelle1.BAnummer and
                            AA.Kriterium = 'ID' and AA.AAStatus <> 'Erledigt' ))
Where Tabelle1.Feld1 = '4EE' and (Tabelle1.Feld2 = 'Frankfurt' or Tabelle1.Feld2 = 'München'

Ich muss leider der Join so machen auf jeden Fall aus meiner Sicht. Eventuell kann es ja jemand besser und gibt mir einen Tip.

Ich beschreibe es mal in Worten
Ich möchte alle Datensätze aus der Tabelle1 haben bei dem im Feld1 4EE und im Feld2 Frankfurt oder München steht. Des weiteren soll noch ein Spalte (AAZaehler) aus der Tabelle2 kommen. Hier ist nun mein Problem. Es können in der Tabelle mehrere Datensätze mit den Kriteren sein. Ich möcht den mit dem größten AAZaheler.

Inhalt der Tabelle2

markieren

Delphi-Quellcode:

AAZaehler AAStatus Kriterium BNummer
1 Erledigt ID 1
2 Offen ID 1
3 Neu ID 1
4 Erledigt ID 1
5 Neu AA 2

Es sollte also bei dem Select aus der Tabelle2 der AAZaehler 3 und nur diser herauskommen.

Danke schon einmal und Entschuldigung das ich Euch zuerst in die falsche Richtung geschickt habe.

Tanja

Die Ursache (fehlender oder ungünstiger Index) läßt sich über den "Query Plan" ermitteln, mit etwas Glück unterstützt IBX den SQL Monitor auch für Firebird: "Use the SQL Monitor" aus dem Artikel "InterBaseExpress: Tips and Tricks".

Eine weitere Möglichkeit ist IBExpert, damit ist (in der professionellen Version) für jede SQL Abfrage auch der Plan ablesbar.

Die dritte Möglichkeit an den Query Plan zu gelangen ist, die Property TIBSQL.Plan auszulesen.

Wenn auf beiden Feldern ein Index liegt, sollte der PLAN auch beide Indexe zeigen.

In der Anlage ein Screenshot von IBExpert.
Wie man da ersehen kann, arbeitet der Optimizer von Firebird (2.52) hier absolut korrekt.


Frank