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

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

[jobo]

Zitat von Der schöne Günther:

Dafür ist mein SQL nicht gut genug, ich verstehe kein bisschen.

Damit bekommst Du in jeder Rückbadezeile die Anzahl der Gesamtdatensätze als zusätzliche Spalte. Brauchst Du nicht.

Wenn ein count(*) schon zu lange dauert (mit einer entsprechend komplexen Bedingung), dann sind andere Sachen angesagt.

1. SQLite ist verbreitet, aber nicht unbedingt schnell
2. langsames SQL ist gern ein Indikator für unpassende Indizierung
3. aus 1 folgt, dass man vielleicht nach Alternativen schaut, unangenehm, aus 2 folgt: viel angenehmer, weil ggF. mit ein paar Handgriffen erledigt.
4. langsames SQL kann auch an einigen oder wenigen oder vielen "OR" Kriterien in der Bedingung liegen, in dem Fall ergibt es dann oft mehere "Fullscans", besonders schlecht bei großen Datenmengen, Singlepass und mitzählen ist dann schneller (was immer das auch erstmal für Dich bedeutet)
5. das alles ruft nach einem Blick auf den Ausführungsplan der Query
6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen
7. ein Queryplan liefert immerhin brauchbare Indizien zu 1.-5., ohne all zu viel über Feldnamen usw. zu verraten
8. ein Queryplan kann man leichter "schminken", als eine komplexe Query
9. hier gibt Anleitung zu Query Plan: https://www.sqlite.org/eqp.html

Wenn Du Dich auf die ein oder andere Art mit Deiner komplexen Bedingung hier outest, kann Dir vielleicht geholfen werden.

[p80286]

Zitat von jobo:

Damit bekommst Du in jeder Rückbadezeile

Dicke Finger?

Zitat von jobo:

6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen

Hmm, da lehnst Du Dich etwas weit aus dem Fenster. Da kann es vielerlei Gründe geben, von "mit dem Kauderwelsch mach ich mich ja lächerlich" bis zum Verrat von Geschäftsgeheimnissen.

Da der schöne Mann nicht mehr ganz grün hinter den Ohren ist, hat er wohl gute Gründe das Original nicht zu Publizieren.

Gruß
K-H

[jobo]

Zitat von p80286:

Dicke Finger?

Zitat von jobo:

6. Leute, die eine "komplexe Bedingung" nicht zeigen (wollen), haben vielleicht was zu verbergen

Hmm, da lehnst Du Dich etwas weit aus dem Fenster. Da kann es vielerlei Gründe geben, von "mit dem Kauderwelsch mach ich mich ja lächerlich" bis zum Verrat von Geschäftsgeheimnissen.

Da der schöne Mann nicht mehr ganz grün hinter den Ohren ist, hat er wohl gute Gründe das Original nicht zu Publizieren.

Ja, die Gicht ..., aber "Rückbaden" ist Althochdeutsch für "Ausbaden" und das müssen wir ja hier wohl alle mal ...


Ja und ich lehn mich natürlich nicht aus dem Fenster, lediglich meine Gedanken scheinen so dick zu sein wie meine Finger.
Ich wollte nur eine Brücke bauen, auch wenn es niemand aufgefallen ist. Ob Scham oder Firmengeheimnis, es ist normal, dass gewisse Dinge nicht in einem Forum gepostet werden.
Das kann natürlich jeder halten wie er will, die Sache mit dem Explain Plan war gewisser maßen eine Alternative dazu.

Letztlich muss man in gewisser Weise "Klartext" reden. Wenn "komplexe Bedingung" ral für 20 x OR steht, kann man sich wahrscheinlich alle möglichen Tricks in die Haare schmieren. Explain wäre erst mal gut für etwas Klarheit.

[p80286]

Zitat von jobo:

Ja und ich lehn mich natürlich nicht aus dem Fenster, lediglich meine Gedanken scheinen so dick zu sein wie meine Finger.

Nö soo dick nu auch wieder nicht. Ich kann mich allerdings noch gut erinnern, was für ein Aufwand/Eiertanz es war eine morsche Abfrage so zu formulieren, daß das wichtige rüber kam und trotzdem keine Rückschlüsse auf die verwendete Datenbank möglich war. Und um die Ohren gehauen zu bekommen, daß eine Tabelle suboptimal angelegt wurde ist auch nicht sooo erheiternd.

@Der schöne Günther
Wenn Du Millionen von Datensätzen erwarten kannst, ist es legitim sich auf die ersten hundert zu beschränken um etwas "Datengeschmack" zu bekommen. Sag mal um was es dir hier wirklich geht, bzw. warum Du die Einschränkung benötigst.
z.B. Die ersten Hundert holen um dem Benutzer Acion zu geben und dann den Rest hinterher, würde ich anders lösen.

Gruß
k-H

P.S.
Die Vorschläge von Jobo solltest Du Dir wirklich zu Herzen nehmen.

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