[Gelöst] .COUNT Performanz ?

Ich habe heute gehört , dass die MS Leute mal gesagt haben sollen dass der COUNT Befehl zum Zählen von Records aus der Performanz Sicht sehr sehr mies ist, und dass es sogar besser ist mit einer Schleife durchzugehen und eine Integer hochzuzählen.

Stimmt das, und wie kann sowas sein ?!

Zuletzt geändert von dayscott am 19. Mai 2009 10:32, insgesamt 1-mal geändert.

Vergleich doch einfach, welche Varainte länger braucht. Ich fand jedenfalls ein count nie großartig langsam. Einzig das Zusammensuchen des zu zählenden Records kann dauern, wenn kein passender Schlüssel gesetzt ist bzw. fehlt.

Beim SQL-Server bin ich mir relativ sicher, dass die Anzahl des records mit übergeben wird. Falls das so ist, wäre ein count auf jeden Fall schneller. Aber um das genau zu wissen, müssen wir wahrscheinlich auf Hilfe des großen Stryk warten

Ich kann mir irgendwie nicht vorstellen, dass von einem MS Mitarbeiter eine solche Aussage kam.

Denken wir doch einmal darüber nach: Ein COUNT(*) liefert mir einen Wert zurück, also die reine Datenlieferung ist schon um ein vielfaches kleiner und kürzer als die Schleife, zumal in beiden Fällen die Einschränkungen/Filter definiert werden müssen. Also selbst wenn die Operationen auf dem SQL Server identisch wären, dann würde COUNT(*) hier besser abschneiden, von den Cursoroperationen in der Schleife mal ganz abgesehen.

Ich würde also tippen, der COUNT ist immer schneller. Brauche ich nur einen groben "Schätzwert" der Anzahl Datensätze, dann immer auf den COUNTAPPROX ausweichen.

Ich kann mir irgendwie nicht vorstellen, dass von einem MS Mitarbeiter eine solche Aussage kam.

Sag bloß, du hast jemals einer Aussage wie "Ich habe gehört, dass irgendwer irgendwas angeblich mal gesagt haben soll" auch nur ein Stückchen Wahtheit entlocken können

Wie Carsten schon schrieb, ist der COUNT gegenüber dem einzelnen durchlaufen der Datensätze schneller, da hier nur die Anzahl Datensätze (anstelle der ganzen Datensätze) zurückgegeben wird.

Auf dem SQL-Server kann man (bei gepflegten SQL-Server-Statistiken) mit dem COUNTAPPROX noch mehr Geschwindigkeit herausholen, da hier nicht physikalisch gezählt, sondern geschätzt wird (Größe der Tabelle / Durchschnittliche Größe der Datensätze = Ungefähre Anzahl Datensätze).

Ähem ... hüstel ... hüstel ...

müssen wir wahrscheinlich auf Hilfe des großen Stryk warten

ich bin mir nicht sicher ob ich mich geehrt oder verar... fühlen soll, und bei dem hohen Erwartungsdruck trau ich mich ja gar nicht mehr zu antworten ...

Also, mein "Senf" zu COUNT:

Ein COUNT setzt einen SELELCT COUNT(*) Befehl ab, mit den gewünschten Filter-Bedingungen (WHERE). Damit dieser COUNT schnell funktioniert, brauch der SQL Server einen entsprecjhenden Index, der die Felder dieser WHERE Clause enthält.
Würde man anstatt des COUNT ein FIND benutzen, dann würde zwar kein SELECT COUNT(*) geschickt werden, sondern ein SELECT * - der Filter - und damit die WHERE Cluase - ist aber der selbe; d.h. es wird der selbe Index benötigt um die Abfrage aufzubauen.
Gleicher Filter = Gleicher Index = Gleiche Leistung (aber: da der FIND eine Cursor-Operation auslöst, wird der vermutlich sogar langsamer sein)

Also, gegen eine gut indizierten COUNT ist nix einzuwenden - und sollte immer verwendet werden, wenn die Anzahl korrekt benötigt wird.

COUNTAPPROX verfährt wie folgt:
Zuerst wird SHOWPLAN_ALL ON gesetzt; d.h. der SQL Server wird nun keine Abfragen mehr AUSFÜHREN, sondern nurmehr einen geschätzen Execution Plan erzeugen.
Dann wird der SELECT COUNT abgesezt - aber wie gesagt: es wird nicht wirklich gezählt (also kein Index wird bemüht). Der nun erzeugte ExecPlan enthält eine Spalte "Estimate Rows", also die GESCHÄTZTE Anzahl der Datensaätze. Diese wird an den NAV Client zurück gegeben.
Danach erfolgt wieder SHOWPLAN_ALL OFF
Da also COUNTAPPROX eigentlich gar keine Operation auf dem SQL Server auslöst, ist dieser natürlich schneller als eine echte Zählung. Aber eben nur eine Schätzung, die nicht unbedingt den Tatsachen entsprechen muss.

Schöne Grüße,
Jörg (und ich bin wirklich nur normal groß, ehrlich)

ich bin mir nicht sicher ob ich mich geehrt oder verar... fühlen soll,

Na hör mal - seh ich aus, als würde ich dich verar... wollen?

Allerdings hätt ich noch eine Frage dazu: wenn mir der Server (SQL oder Native) nach einem SetRange-und-findset ein Recordset übergibt: hat er die Menge an Datensätzen beim Zusammenstellen des Sets nicht gleich mitgezählt (und mit übergeben oder auf Anfrage parat)?

Also bei "native" weiss ich's nicht, aber der SQL Server kennt die Anzahl natürlich schon - die könnte man z.B. über die Variable @@rowcount auslesen ... soviel ich weiß, nutzt aber NAV dieses Feature nicht ...

Also bei "native" weiss ich's nicht, aber der SQL Server kennt die Anzahl natürlich schon - die könnte man z.B. über die Variable @@rowcount auslesen ... soviel ich weiß, nutzt aber NAV dieses Feature nicht ...

Irgendwie an der falschen Stelle gespart

Ich kann mir irgendwie nicht vorstellen, dass von einem MS Mitarbeiter eine solche Aussage kam.

deswegen steht meine Aussage auch im Konjunktiv I !

viele dank für euere Antworten!

wann wird Countapprox in der Praxis tatsächlich eingesetzt ? Also wann will ich "ungefähr" die Anzahl der Datensätze wissen ? (weil: ungefähr := ein sehr fuzzy'es Wort)

wann wird Countapprox in der Praxis tatsächlich eingesetzt ? Also wann will ich "ungefähr" die Anzahl der Datensätze wissen ? (weil: ungefähr := ein sehr fuzzy'es Wort)

Zum Beispiel bei aufwendigen Reports, um in einem Fortschrittsdialog Auskunft über die vermutliche Wartezeit zu geben, oder dem Benutzer wenigstens zu zeigen, dass das System noch arbeitet. Wenn man bedenkt, dass manche COUNT-Abfragen bis zu einer Minute brauchen, ein COUNTAPPROX aber nur zwei Sekunden, ist die Entscheidung in einem solchen Szenario recht schnell getroffen.