Select Count(*) vs. Select First 1

[TigerLilly]

Zitat von IBExpert:

Zitat von TigerLilly:

Ob Tuning in einem solchen Bereich überhaupt Sinn hätte, wäre halt auch zu überlegen.

Naja, das Tuning generell ist schon extrem hilfreich, je größer die DB um so eher bringt das was, zumindest
bezogen auf firebird.

Cool, dass du das überprüft hast.

Tuning ist wichtig, klar. Aber das worum es hier in dem Thread ging, ist Microtuning + weist in der Regel auf schlechtes Design hin. Oder Nerd-Interesse.

Womit die ursprüngliche Frage des TE beantwortet wäre?

[jobo]

Ja, harte Fakten sind cooler als bloßes Gerede.

Ich kann aber Deinen Ausführungen nicht folgen.
"Select Count(*) vs. Select First 1" ist microtuning und unwichtig?
(Normales) Tuning ist aber wichtig?

Der Begriff microtuning scheint mir außerdem nicht wirklich klar.
Wenn ich ihn definieren müsste, wäre es ganz sicher nicht die Frage ob First, Exists oder Count einzusetzen wäre.
Und was hat (micro)tuning- was immer es auch ist- mit schlechtem Design zu tun?

[hoika]

Hallo,
das betreffende Programm hat schon ein paar Jahre auf dem Buckel.
Ursprungs-DB war Interbase 4... Da gab es Select First nicht
Ich schaue mir auch alten SQL-Code z.B. per DB-Monitor an.

In meiner Test-DB fallen mir dann schon ein paar Sachen auf, ich oller Nerd...

Test-DB: "fully populate your Database"

[p80286]

Zitat von IBExpert:

Das ist an sich noch nichts wo man vor Erfurcht zusammenbrechen muss ...

sollst Du auch nicht, mir ging es eher darum klar zu machen, daß es in der Praxis vor dem Client ab einer gewissen Zeitspanne egal ist ob ein zwei Zehntel eingespart werden.

Gruß
K-H

[TigerLilly]

@jobo:
Tuning stelle ich mir gerne wie eine Pyramide vor: unten breit und oben schmal. Unten sind die wirklichen Basics: Datenstrukturen. Indizes. Hardware. Speicher. Platten.
Oben ist das, was ich Microtuning nenne, kleinste Maßnahmen in ganz isolierten Situationen. Wo man sich überlegt, ob die Länge von Tabellennamen Einfluss auf die Performance hat.

Meiner Erfahrung nach sind die Basiscs viel wichtiger. Wenn du unpassende Indizes hast, helfen schnelle Platten auch nichts. Wenn deine Datenstruktur die benötigten Zugriffspfade nicht unterstützt, helfen dir die perfekten Indices auch nicht weiter.

Tuningmaßnahmen ganz oben,wo es um das Ausreizen auch noch des kleinsten Performancegewinns geht, haben nur ganz selten Sinn. Das geht nur, wenn das System insgesamt ganz stabil ist + es so gut wie keine Änderungen mehr gibt. Und auch dann bedarf das dauernder Überprüfung und Steuerung.

Die ursprüngliche Frage des TE war, welches Konstrukt für das Feststellen der Existenz eines Datensatzes schneller ist.
Ich glaube, wenn man aus Performancegründen über so was nachdenken muss, stimmt was am Design nicht. Vielleicht wäre es besser, vorab Zwischendaten zu erzeugen, so dass man diese Abfrage gar nicht mehr braucht, oder man sorgt dafür, dass es immer genau einen Datensatz gibt, dann muss man auch nichts prüfen. Oder ich lagere das in eine StoredProcedure aus. Oder. Oder. Oder.

Meine Tuningmaßnahme muss als Einzelmaßnahme sinnvolle Wirkung zeigen (=Index beschleunigt eine WHERE Abfrage) und nicht erst durch Wiederholung (=ich spare 10ms ein, aber weil das in einer Schleife ist, die 1000x ausgeführt wird, sind das auch 10sec). Ersteres ist gut + sinnvoll, bei zweiterem sollten Alarmglocken läuten.

[hoika]

Hallo,
Microtuning?, den Begriff musste ich erst mal nachschlagen

Zitat:

Ich glaube, wenn man aus Performancegründen über so was nachdenken muss, stimmt was am Design nicht.

Ich habe hier Code aus guten Interbase-Zeiten.
Wenn ich mit einer Änderung im SQL-Code eine neue Funktionalität meiner Datenbank nutze,
nenne ich das Optimierung. Wenn das First wieder erwarten langsamer wäre, würde ich natürlich den Code nicht anfassen.

Und klar ist es richtig:
Was nützt mir die besten Optimierung, wenn beim Kunden ein lahmer Server steht
oder das Netzwerk sehr langsam ist.

Und klar ist auch:
Ich aus 2 Mio. Einträgen wissen, ob ein bestimmter Eintrag mindestens einmal vorhanden ist, z.B. Daten eines Quartals.
Das Ergebnis sind z.B. 10.000 Einträge.
Ich könnte jetzt per Count(*) zählen und dann mit >0 prüfen, oder mir den ersten Wert geben und mit Is not Null prüfen.
Egal, ob ein Index vorhanden ist, auch dessen Pages müssen u.U. von der Festplatte geladen werden.

D.h., ich sage dem Kunden nicht, kaufe dir ne SSD, damit der Index schneller geladen wird, sondern ich ändere den Code ab,
so dass der Index eben nicht vollständig bzw. teilweise geladen werden muss.

[bnreimer42]

Zitat von hoika:

...

Und klar ist es richtig:
Was nützt mir die besten Optimierung, wenn beim Kunden ein lahmer Server steht
oder das Netzwerk sehr langsam ist.

Gerade da lohnt sich Tuning, denn da hat es Auswirkungen, die der Anwender merkt. Auf modernen schnellen Servern lohnt Mikrotuning meiner Ansicht nach nur, wenn eine Abfrage wirklich extrem oft läuft. Und da ist Caching im Client oder besser in er Middleware eine Option.