Select Count(*) vs. Select First 1

[hoika]

Hallo,
ich arbeite nur mit Firebird, also gibt es das First auf jeden Fall.

Zitat:

Klar, das count(*) muss einen kompletten Fullscan machen (wenn nicht Indizes benutzt werden können)

Es werden Indizes benutzt.

Also sollte man auf jeden Fall davon ausgehen,
dass das First schneller als das Count(*) ist, richtig?.

[TigerLilly]

RecordCount wird am Client(!) ermittelt + kann bei genug Datensätzen lange brauchen, weil alle Datensätze abgerufen werden + gezählt werden. Das war auch nicht die Frage. :-/

select first 1 vs select Count(*) vs select count(1) vs select 1 ist alles gleich schnell. Da wiegt Netzwerk, Latenz und Parsezeit viel mehr.

[Poelser]

Zitat von hoika:

Also sollte man auf jeden Fall davon ausgehen,
dass das First schneller als das Count(*) ist, richtig?.

Das würde ich nicht unbedingt unterschreiben.
Adaptive Server Anywhere z.B. meckert beim First rum, dass das Ergebnis nicht deterministisch sein würde. Zurecht, denn die DB-Engine weiß ja nicht, dass mir der Inhalte des zurückgelieferten Datensatzes in diesem Fall egal ist.
Das umgeht man, indem ein Order By benutzt wird - und damit könnte wieder ein Full Table Scan drohen.

[TigerLilly]

Wenn(!) ein Full Table Scan notwendig ist, dann ist er das bei Count(*) Count(1) first 1 auch.
Es ist wirklich egal + es gibt kein Szenario, wo eines schneller wäre.

Und Achtung: wir reden hier von FB und nicht dBase.

[jobo]

Wieso sollte ein First in FB und ohne Angabe von Order by nicht schneller sein?
Ich habe selber schon geschrieben, dass es natürlich eine Frage der Implementierung ist, aber es würde sehr viel Sinn machen, nach der verlangten Anzahl Datensätze abzubrechen. Das kann count nicht.

[Poelser]

Wenn FB (nutze ich allerdings nicht) einen SELECT FIRST 1 ohne Order By zulässt, dann ist das sicher schneller. Ich hatte mit ASA (welches eben Order By braucht) die schnellsten Ergebnisse mit SELECT 1 FIRST 1 ORDER BY 1. Das funktionierte rattenschnell, und zwingt auch dazu, die erste Spalte als PK-Spalte zu haben

[hoika]

Hallo,

Zitat:

Adaptive Server Anywhere z.B. meckert beim First rum, dass das Ergebnis nicht deterministisch sein würde. Zurecht, denn die DB-Engine weiß ja nicht, dass mir der Inhalte des zurückgelieferten Datensatzes in diesem Fall egal ist.

Das habe ich gar nicht verstanden

Ich mache ein Select First 1 Id From Table1, das liefert mit den ersten Werte des Feldes Id, Reihenfolge ist hier auch egal.

Ich hatte irgendwo auch mal gelesen, dass Exists hier noch schneller ist:
Select 1 From RDB$DataBase Where Exists (Select First 1 Id From Table1)
Durch das Exists wird wohl noch schneller gesucht.

http://www.janus-software.com/fbmanu...=psql&topic=85

Ja, ich weiss er vergleicht mit Count(*).

[jobo]

Zitat von hoika:

Ich mache ein Select First 1 Id From Table1, das liefert mit den ersten Werte des Feldes Id, Reihenfolge ist hier auch egal.

Ich hatte irgendwo auch mal gelesen, dass Exists hier noch schneller ist:
Select 1 From RDB$DataBase Where Exists (Select First 1 Id From Table1)
Durch das Exists wird wohl noch schneller gesucht.

Die Kernanmerkung (Unterschied zu FB FIRST) bei adaptive ist ja wohl, das adaptive das FIRST nur akzeptiert, wenn ein ORDER dabei ist. M.E. eine etwas schwache (oder pingelige) Implementierung. Wenn FB das FIRST ohne ORDER akzeptiert, tut es genau das, wozu es nach Deiner Anforderung in diesem THREAD eingesetzt wird.
(Würde man ein ORDER hinter das FIRST packen, käme vielleicht ein anderer Datensatz an erster Stelle, das Order zwingt aber genau wie das COUNT zu einer vollständigen Suche)
Es geht aber nur darum, ob 1 Datensatz EXISTiert.


Womit wir bei der EXIST Variante wären. Das Beispiel das Du anführst ist m.E. doppelt gemoppelt. Die Arbeit macht das FIRST Statement am Ende in Klammern. Das nochmal mit EXISTS abzufragen, bringt m.E. gar nichts. (Den Zusatzaufwand die Rückgabe von FIRST erneut zu prüfen, mal vernachlässigt, ansonsten wäre die Kombi EXISTS plus FIRST m.E. marginal sogar langsamer)