Hallo,
bei einer üblichen Performance-Analyse sehe ich mal wieder alten Code mit dem üblichen Select Count(*) .

Um festzustellen, ob es einen Datensatz bereits gibt,
kann ich ja Select Count(*) oder Select First 1 nehmen.

Nehmen wir mal, an das Ergebnis das Count(*) wären 20 Einträge.
Ist das Select First 1 nicht perse schneller,
weil beim Finden des ersten Datensatzes sofort abgebrochen wird?
Ich benutze ein normales Where, kein Like, der Index wird also direkt benutzt.

Das Suchfeld ist natürlich indiziert und nicht der Primary Key.

Was meint ihr?

Klar, das count(*) muss einen kompletten Fullscan machen (wenn nicht Indizes benutzt werden können)
Das First start sicher anlaog mit einem Fullscann, kann aber abbrechen. Wenn es auch so implementiert ist, dass es das tut, ist es schneller.

Es gibt Dialekte bzw Komponenten, die kein RecordCount zulassen. In diesen Fällen ist es sicherer so:

markieren

Delphi-Quellcode:

select
  count(1) RecCount
from
  t_tabelle
;

Zitat von ConnorMcLeod:

Es gibt Dialekte bzw Komponenten, die kein RecordCount zulassen. In diesen Fällen ist es sicherer so:

markieren

Delphi-Quellcode:

select
  count(1) RecCount
from
  t_tabelle
;

Wenn man mit Select First 1/Top 1 arbeitet, so braucht man kein RecordCount, sondern nur die Abfrage ob man überhaupt einen Datensatz nach dem öffnen der Query vor sich hat (.EOF).

Zitat von Bernhard Geyer:

EOF

Stimmt, zugegeben. Ich hatte früher mal Schwierigkeiten mit Bof und Eof, daher vermeide ich es seit damals, wenn möglich. Mit Ausnahme von while not eof do next natürlich...

Nur wenn das "select count(1) RecCount" auf Grund der angegebenen Bedingung genau einen Datensatz ermittelt, ist es gleich schnell.

Zitat von Blup:

Nur wenn das "select count(1) RecCount" auf Grund der angegebenen Bedingung genau einen Datensatz ermittelt, ist es gleich schnell.

Gleich schnell wie was?

Zitat von hoika:

Hallo,
bei einer üblichen Performance-Analyse sehe ich mal wieder alten Code mit dem üblichen Select Count(*) .

Was für eine Performance?
Falls das Count wirklich auf dem Client stattfinden sollte, was ich für einige DBMS ausschließen kann, mißt Du hier eine fröhliche Summe von Einflußfaktoren. Wenn das Ergebnis nicht schnell genug zur Verfügung steht, kann alles mögliche hierauf Einfluß haben.
Wird das Count auf dem Server ausgeführt, hat man zumindest eine Näherung zu was die DB auf dem Server bei der augenblicklichen Konfiguration in der Lage ist.

Gruß
K-H

Zumindest bei den mir zur Verfügung stehenden Oracle-DB ist Count(*) immer sauschnell 10 Mio-Datensätze <3 sec
Was leider keine Aussage über die Datenbereitstellung anderer Abfragen erlaubt.

Zitat von p80286:

Zumindest bei den mir zur Verfügung stehenden Oracle-DB ist Count(*) immer sauschnell 10 Mio-Datensätze <3 sec
Was leider keine Aussage über die Datenbereitstellung anderer Abfragen erlaubt.

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

Leider benutzen viele Kunden irgendwelche Server, die irgendwas sicher auch ganz schnell können,
aber für Firebird kompletter Schrott sind und trotzdem sauteuer.

Wenn man die dann mit sauteuren uund hochoptimierten Oracle oder MSSQL Servern vergleicht,
kommt da nichts bei raus. Und frag am besten weder Dell, HP noch Lenovo nach geeigneter
Firebird Hardware, die Systemhäuser stellen da nur teuren Quatsch zusammen.

Diesen Test hab ich gerade auf einer Kunden DB gemacht, count(*) für ca 3mio Datensätze
in ca. 0,6 Sekunden

Die Serverhardware ist von uns geliefert, kostet mit 1TB ca 3500 € und schafft
einen IBExpert Firebird Benchmark von >=500% Driveindex und >=300% CPU Index
und ist transaktionsecht live auf einer zweiten baugleichen Maschine repliziert.

Vermutlich ab nächste Woche bieten wir die auch wieder außerhalb von Kundenprojekten an
und im Herbst machen wir damit vermutlich mal wieder eine Roadshow.

markieren

Code:

query:

Select count(*) from brpst

COUNT
2979487

Plan
PLAN (BRPST NATURAL)

------ Performance info ------
Prepare time = 16ms
Execute time = 625ms
Avg fetch time = 625,00 ms
Current memory = 1.171.921.280
Max memory = 0
Memory buffers = 40.000
Reads from disk to cache = 6.955
Writes from cache to disk = 2
Fetches from cache = 0

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