BETWEEN schneller machen?

[ryLIX]

Moin,

ich hab hier ein SELECT stmt welches eindeutig zu langsam ist (bei 800MHZ 1249ms).
Derzeit benutze ich in diesem stmt BETWEEN um meine Daten zu bekommen.
Das Ergebnis ist zwar wie gewünscht aber es dauert zu lang.

SQL-Code:

SELECT fgstnr_prod, fgstnr_mospid, fgstnr_typschl FROM vin_fgstnr WHERE "EH03029" BETWEEN fgstnr_von AND fgstnr_bis

Ich hab hier mal einen Schlüssel eingefügt um zu verdeutlichen wie die aussehen ;)

Zur Tabelle:
Im stmt sind schon fast alle Spalten drin.
Eine gibts noch die ich derzeit nicht verwende: fgstnr_anf
Die enthält die ersten beiden zeichen des Schlüssels.
Die Tabelle enthält um 1.5 mio Datensätze.

Nun suche ich nach einer Möglichkeit die Daten schneller zu filtern.

Wenn ich nur nach fgstnr_anf Frage bekomme ich um 1000 Datensätze.
Wäre es besser das Query darüber aufzubauen und dann mit Delphi die Daten zu Filtern?
Wenn ja wie finde ich den passenden Datensatz? Da es sich bei den Schlüsseln immer um einen Bereich handelt.

Gibt es noch andere alternativen?

[mkinzler]

Was für Indizes existieren?

[ryLIX]

Derzeit keine.
Gibt auch keine Unique Felder.

[mkinzler]

Indizes sind aber das Instrument der Wahl um Abfragen zu optimieren.

[khh]

Zitat:

Zitat von ryLIX

Derzeit keine.
Gibt auch keine Unique Felder.

ein index auf die relevanten felder beschleunigt den Zugriff um das x-fache


Gruss KH

[ryLIX]

Der Index sollte dann für _von und _bis sein oder?
Muss ich an der Abfrage noch etwas verändern?

[omata]

Zitat:

Zitat von ryLIX

Muss ich an der Abfrage noch etwas verändern?

Nein, die ist doch schon minimalistisch.

[mkinzler]

Zitat:

Der Index sollte dann für _von und _bis sein oder?

Deine Abfrage isz zwar atypisch für eine between-Abfrage aber ein Index über ide beiden Spalten sollte passend sein

[ryLIX]

Den Index hab ich nun mal erstellt aber wirklich geändert hat sich nichts an er Geschwindigkeit :?

SQL-Code:

CREATE INDEX [IDX_VIN_FGSTNR_] ON [vin_fgstnr](
[fgstnr_von]  ASC,
[fgstnr_bis]  ASC
)

[Dax]

Lege probeweise mal zwei Indizes an, einen für jede Spalte.

[DeddyH]

Richtig, so gilt er ja für die Kombination der beiden Spalten.

[ryLIX]

Auch keine Besserung :(
Eher schlechter... Abfragezeit liegt nun bei 2245ms

[khh]

Zitat:

Zitat von ryLIX

Auch keine Besserung :(
Eher schlechter... Abfragezeit liegt nun bei 2245ms

also schlechter kann eigentlich nicht sein


hast die abfrage mal direkt in der DB gemacht?

[ryLIX]

Zur Zeitprüfung nutze ich SQLiteAdmin da es ja kein direktes Interfcae für SQLite gibt.

[khh]

Zitat:

Zitat von ryLIX

Zur Zeitprüfung nutze ich SQLiteAdmin da es ja kein direktes Interfcae für SQLite gibt.

hast du mal nur nach einem einzigen feld abgefragt und die zeit mit und ohne index verglichen ?

[ryLIX]

Mit Index: 749ms
Ohne Index: 561ms :gruebel:
Beides Durchschnitt aus 3 gesendeten Abfragen.
:wiejetzt:

Verwendetes Qry:

SQL-Code:

SELECT fgstnr_mospid FROM vin_fgstnr WHERE "EW03029" BETWEEN fgstnr_von AND fgstnr_bis

[mkinzler]

Komisch :gruebel:

[sx2008]

Dann löse doch mal BETWEEN in Einzelbedingungen auf.
Wäre ja möglich, dass der Query Analyser von SQLite nicht schlau genug ist, um die Anwendung von Indizes zu erkennen:

SQL-Code:

SELECT fgstnr_mospid FROM vin_fgstnr WHERE (fgstnr_von <= 'EW03029') AND (fgstnr_bis >= 'EW03029')

[ryLIX]

Keine Änderung durch die Auflösung...
Die höheren Geschwindigkeiten bei den einzelnen Spalten (wie oben angegeben)
Resultieren daraus das ich grad auf höherer Geschwindigkeit arbeite.

Bei 800MHZ sind die Geschwindigkeiten so:
mit 3869ms
ohne 1560ms

Bei Aufgelöstem Qry:
mit 2574ms
ohne 1607ms

:(

[khh]

Zitat:

Zitat von ryLIX

Keine Änderung durch die Auflösung...
Die höheren Geschwindigkeiten bei den einzelnen Spalten (wie oben angegeben)
Resultieren daraus das ich grad auf höherer Geschwindigkeit arbeite.

Bei 800MHZ sind die Geschwindigkeiten so:
mit 3869ms
ohne 1560ms

Bei Aufgelöstem Qry:
mit 2574ms
ohne 1607ms

:(

wirklich eigenartig.
hat du die Möglichkeit die Daten zum Test in eine andere DB zu importieren und die Abfrage dort auszuführen?

[KingIR]

Was für eine Festplatte verwendest du in einem 800Mhz-Rechner? SQLite cached wenig im RAM, wenn deine DB da eine gewisse Größe erreicht, wird schnell die Festplatte zum merkbaren Flaschenhals.

[khh]

Zitat:

Zitat von KingIR

Was für eine Festplatte verwendest du in einem 800Mhz-Rechner? SQLite cached wenig im RAM, wenn deine DB da eine gewisse Größe erreicht, wird schnell die Festplatte zum merkbaren Flaschenhals.

das kann natürlich auch sein, begründet aber nicht, dass die Abfragen mit Index langsamer sind als die ohne

[alzaimar]

A) Entweder SQLite ist doch nicht so toll, oder
B) die Messreihenfolge hat Auswirkungen auf das Ergebnis (Cache).

Für A: Prüf mal, indem Du die Query umschreibst (Siehe Post von sx2008). Wenn das dann schneller geht, ist SQLite zu 'lite', um beim BETWEEN einen Index zu verwenden.
Für B: Vertausche die Messreihenfolge in deinem Testprogramm. Wenn das dann schneller geht, weißt Du Bescheid :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von alzaimar

A) Entweder SQLite ist doch nicht so toll, ...

Würde ich nicht ausschließen. Bei meinen Tests mit diversen Desktop-DBs war SQLite beim Update von Datensätzen um Welten langsamer als jede andere Desktop DB.

Auch würde ich versuchen die letzte Version (Version 3.6.11) einzusetzen. In der News-Liste steht ab und zu mal was von Performance-Verbesserung. Da du DISQLite3 verwendest müsstet du versuche mit ZESO auf den orginal DLL's zu arbeiten um zu sehen ob evtl. die Delphi-Portierung hier einfach nur fehlerhaft ist bzw. nicht auf den Stand der "normalen" Implementierung.

[ryLIX]

SQLite Admin basiert auf den ZEOS Komponenten.

Als Festplatte steck hier im Laptop eine SATA2 Festplatte.
Ist zwar eher mittelmaß aber ausreichend.

Das Problem liegt auch genau bei diesem Query.
Wenn ich nur nach _mospid oder _tyschl Abfrage geht das ganze unter 500ms bei 800MHZ

Deswegen hatte ich überlegt ob es nicht besser wäre über Delphi Code die passende Range zu suchen.
Da die Abfrage über _anf wesentlich schneller ist.