Firebird SELECT BETWEEN etxrem langsam

[mlc42]

Hallo,

ich habe ein seltsames Verhalten bei Firebird entdeckt. Abfragen mit BETWEEN sind teilweise unglaublich langsam.

Beispiel Tabelle mit einigen 100.000 Datensätzen Felder (ID,DATUM,NUMMER,....)

Sekundärer Index auf ID,DATUM,NUMMER ist gesetzt



SELECT * FROM tabelle WHERE (ID BETWEEN 1000 AND 1000) AND (DATUM BETWEEN '01.01.2013' AND '01.01.2013') ORDER BY ID,DATUM,NUMMER
Dieser SQL dauert um die 9 Sekunden und liefert in meinen Daten ca. 8 Datensätze zurück.
Laut Plan nimmt Firebird den INDEX ID,DATUM,NUMMER. Die Platte hört sich aber so an als wenn er mehr macht. Flamerobin zeigt 70.000 Fetches an.




SELECT * FROM tabelle WHERE (ID = 1000) AND (DATUM = '01.01.2013') ORDER BY ID,DATUM,NUMMER (Was in diesem Fall geht da die Grenzen gleich sind)
Dieser SQL dauert 0,09 Sekunden.

Festplatten Cache, Firebird Cache habe ich vor jedem Test geleert. Sonst merkt man das nicht.

Der gleiche SQL wird in meinem Programm auch auf einen MS-SQL Server abgesetzt. Da ist es immer sehr schnell.

Ich habe das bei mir so in ANYDAC geändert, das BETWEEN mit gleichen Grenzen durch = ersetzt wird. Dann funktioniert mein Programm auch auf Firebird
so schnell wie man das bei dieser einfachen Afrage erwarten sollte.

Kennt jemand die Ursache für dieses Verhalten ?

mfg
Martin

[jobo]

Welchen Typ hat das Datumsfeld?
Falls es nicht String ist, dürfte der Index für den Datumsteil hier nutzlos sein.

[mlc42]

Das Datum ist timestamp die anderen Felder sind Int.
Wenn ich nur die ID Abfrage auf = ändere und Datum auf BETWEEN lasse geht es auch schon schnell.
Ich weiß ja nicht wie Firebird das intern speichert, Aber in Delphi ist das ja ein Float und der ist ja auch aufsteigend sortiert.

Gruß Martin

[jobo]

Zitat:

Zitat von mlc42 (Beitrag 1202723)

Das Datum ist timestamp die anderen Felder sind Int.

Dann solltest Du entweder explizit Deinen Datums-String in Timestamp konvertieren oder in Delphi - falls Du es von dort aufrufst- mit Parametern und natürlich den richtigen Typen arbeiten.

Zitat:

Zitat von mlc42 (Beitrag 1202723)

Wenn ich nur die ID Abfrage auf = ändere und Datum auf BETWEEN lasse geht es auch schon schnell.

Hier dürfte durch die Gleichheitsprüfung die Ergebnismenge auf einen Schlag so stark eingeschränkt sein, das der Rest vom Verarbeitungsaufwand nicht ins Gewicht fällt, Egal wie schlecht oder aufwändig die Abfrage da noch gestaltet ist.

Zitat:

Zitat von mlc42 (Beitrag 1202723)

Ich weiß ja nicht wie Firebird das intern speichert

Du hast alle benötigten Typinformationen (hast Du oben geschrieben), was Firebird intern macht, weiß ich auch nicht, kann, soll, muss ich auch nicht, genau wie Du.

Also schau Dich um, wie man Abfragen parametrisiert, den Parametertyp setzt und ab die Post...

[IBExpert]

nimm mal 3 Einzelindizes für die felder statt einem kombinierten index, den am besten löschen.
Bei deiner Abfrage mit den Betweens hast du ab dem ersten Eintrag keine sinnvolle Wirkung
mehr für deinen kombinierten Index

[mlc42]

@jobo

Die Abfrage wird innerhalb ANYDac erzeugt und arbeitet mit Parametern. Das mit dem Beispiel habe ich dann nur gemacht um das ganz einfach prüfen zu können.
Es macht aber keinen Unterschied.
Über den ID Index sind es ca. 7000 Datensätze. Bei der Between Abfrage kommt ja die gleiche Menge raus. Über den Index kann er ja auch da unmittelbar im Index aufsetzen.
Es ist schon seltsam.
Bei Paradox setzt so ein Range ja einfach den Zeiger auf den ersten passenden ID,DATUM und gibt dann an Hand des Schlüssels solange Datensätze aus bis es halt nicht
mehr passt.
Der MS-SQL Server macht das auch blitzschnell.

@IBExpert

Warum hat der kombinierte Index bei Between keine Wirkung mehr ? Wie soll Firebird das sonst schnell sortieren oder suchen können ?
Kombinierte Indices sind ja schon notwendig.
Ich werd mal probieren wie das dann aussieht.

[Furtbichler]

Firebird sieht nicht, das die untere und obere Grenze der ID beim BETWEEN identisch ist, ganz einfach.