BETWEEN schneller machen?

[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 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

[Bernhard Geyer]

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.