Ergebnismenge beschränken mit "LIMIT" oder "TOP"

[Der schöne Günther]

Ein

Code:

SELECT COUNT(*) where Bedingung

kann ich mir nicht leisten, die Bedingung ist komplex.

Das dauert so lange dass man sich erst einmal einen Kaffee holen kann. Zumindest wenn in der Datenbank schon ein paar Millionen Datensätze stecken.

[Lemmy]

Zitat von Der schöne Günther:

Ein

Code:

SELECT COUNT(*) where Bedingung

kann ich mir nicht leisten, die Bedingung ist komplex.

Das dauert so lange dass man sich erst einmal einen Kaffee holen kann. Zumindest wenn in der Datenbank schon ein paar Millionen Datensätze stecken.

das ist doch schon mal was. Wenn die Abfrage wirklich so lange dauert, dann würde ich nicht nur hundert DS abrufen sondern deutlich mehr, bei einer lang laufenden Abfragen spielt dann ein Fetch von ein paar Sekunden dann auch keine Rolle mehr. Die Anzeige in der Oberfläche kannst Du dann anhand der lokalen Datenmenge einschränken und kannst dann deine Anzeige entsprechend gestalten, dass der Anwender noch mehr Datensätze abrufen kann..

[Der schöne Günther]

Vielen Dank für alle Antworten. Auf drei Seiten habe ich es mit einer Frage schon lange nicht mehr geschafft

Ich kann meine Tabellenstruktur und Query gerne zur Diskussion stellen, die Frage "Wie optimiere ich diese spezielle Query?" ist dann aber sicher ein eigenes Thema wert.

Ich muss noch einmal klarstellen:

1. Ich habe kein Performance-Problem. Typischerweise wird die Treffermenge nach einem Zeitstempel eingeschränkt, auf diesem liegt ein Index. Typischerweise sind immer die neusten interessant. Es macht nur Sinn wenn diese GEORDNET nach Zeit aufeinander folgen.
2. Ich habe die Query nun auf tausend Treffer limitiert und bekomme auch in gigabyte-großen Datenbanken mein Ergebnis in wenigen Millisekunden
3. Das Select COUNT(*) dauert, denke ich, so lange nicht weil die Bedingung zu komplex wäre, sondern weil wir hier über große Daten- und Treffermengen sprechen.
4. Ich bin mit der "+1"-Lösung zufrieden denn an sich entspringt kein Nutzen wenn ich weiß dass ich theoretisch 1,4 Millionen Treffer hätte haben können wenn der Arbeitsspeicher unendlich wäre.

Mein Anwendungsfall ist ein Datengrab in das kontinuierlich neue Messwerte gesteckt werden. Die Datenbank wird verwendet um entweder einen bestimmten Zeitbereich später genauer untersuchen zu können oder z.B. eine grafische Auswertung über einen längeren Zeitraum (mehrere Tage) zu malen. Dabei kommt es typischerweise vor dass man mehr über die jüngste Vergangenheit wissen will, trotzdem sollte man auch ein paar Monate zurück reisen können.

Für die ganz neugierigen, das war (ungefähr) die Query:

Code:

select
   tabelle1.pkey,
   [zeitstempel],
   [kurzerText],
   [kommazahl],
   [ganzzahl]
FROM
   tabelle1 JOIN tabelle2
ON
   (tabelle1.pkey = tabelle2.tabelle1_pkey)
WHERE
   (
      ((tabelle1.zeitstempel >= :timeMin) OR (CAST(:timeMin as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.zeitstempel <= :timeMax) OR (CAST(:timeMax as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.kurzerText = :textParameter) or ( CAST(:textParameter as SQL_VARCHAR) is NULL ))
   )
ORDER BY [zeitstempel] DESC LIMIT 1000;

[mkinzler]

Wirklich

Zitat:

SQL-Code:

ON
   (tabelle1.pkey = tabelle1_pkey)

?

-Die Prüfung auf NULL der Parameter besser vor dem Filter der Tabelle auf den Parameter ( (( CAST(:textParameter as SQL_VARCHAR) is NULL ) or (tabelle1.kurzerText = :textParameter)) )

-Möglicherweise hilft eine DERIVED TABLE

[Der schöne Günther]

Zitat von mkinzler:

Wirklich?

tabelle1_pkey ist der FKEY von tabelle2 auf tabelle1 . Ja. Habe ich was dummes gemacht?

Zitat von mkinzler:

Die Prüfung auf NULL der Parameter besser vor dem Filter

Guter Tipp.

Derived Tables höre ich zum ersten mal, ich schaue mal was das ist...

[Jumpy]

Zitat von Der schöne Günther:

Zitat von mkinzler:

Wirklich?

tabelle1_pkey ist der FKEY von tabelle2 auf tabelle1 . Ja. Habe ich was dummes gemacht?

Ich hab auch erst gestutzt, weil ich "tabelle1.pkey = tabelle1.pkey" gelesen hatte und dann erst nachher gesehen habe, das da ja ein Unterstrich war. Mit "tabelle2.tabelle1_pkey" wäre es vllt. nicht so ins Auge gesprungen.

[Der schöne Günther]

Das stimmt, ich habe es abgeändert. Danke.

[jobo]

Wieso war ich der Meinung, dass es um SQLite geht?
Keine Ahnung.

Letztlich scheint sich ja alles in Wohlgefallen aufzulösen, auch wenn ich da zwischendrin Widersprüche sehe.

Zitat von Der schöne Günther:

[*]Ich habe kein Performance-Problem.

Zitat von Der schöne Günther:

Ein

Code:

SELECT COUNT(*) where Bedingung

kann ich mir nicht leisten, die Bedingung ist komplex. Das dauert so lange dass man sich erst einmal einen Kaffee holen kann. ..

"Datengräber" sind ja dann vielleicht auch wie der Name andeutet nicht unbedingt etwas für adhoc Zugriff. Bewegung im Grab ist langsam. Will man trotzdem "at your fingertips" haben, geht es Richtung Datawarehouse, Starschema usw., die Daten werden nicht nur begraben, sondern man notiert sich einmalig wann, wieviel, wovon, wo und bietet das zum Browsen an.

Jenseits von SQLite gibt es natürlich in echten RDBMS und ohne gleich ein Datawarehouse zu eröffnen auch Technologien, die eine bessere Skalierung der Zugriffszeiten ermöglichen, "Partitionierung" mal als ein Stichwort.

[p80286]

Ich habe mit der Abfrage ein leichtes Problem

Zitat von Der schöne Günther:

SQL-Code:

select
   tabelle1.pkey,
   [zeitstempel],
   [kurzerText],
   [kommazahl],
   [ganzzahl]
FROM
   tabelle1 JOIN tabelle2
ON
   (tabelle1.pkey = tabelle2.tabelle1_pkey)
WHERE
   (
      ((tabelle1.zeitstempel >= :timeMin) OR (CAST(:timeMin as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.zeitstempel <= :timeMax) OR (CAST(:timeMax as SQL_TIMESTAMP) is NULL))
   AND
      ((tabelle1.kurzerText = :textParameter) or ( CAST(:textParameter as SQL_VARCHAR) is NULL ))
   )
ORDER BY [zeitstempel] DESC LIMIT 1000;

Das liest sich wie, wenn keine Werte (min,max,text) übergeben werden, dann liefere alles!
Wahrscheinlich gibt es in der GUI eine Logik, die das verhindert aber Unbehagen bereitet mir das trotzdem.
Ad hoc würde ich da drei Abfragen verwenden.

Gruß
K-H

[jobo]

Naja, halt die letzten 1000?