Select Count(*) vs. Select First 1

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

[TigerLilly]

Das hat früher mal gestimmt, aber heute nicht mehr. Moderne query analyzer - und FireBird hat so was - erkennen diese Situationen und erzeugen idente execution plans.
Für ASA mag das nicht oder anders gelten, es implementiert den SQL92 Standard nicht vollständig.
Es gilt aber sicher für MS-SQL, Oracle, IB, FB.

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

[jobo]

Na, wenn die das alle können, worüber reden wir dann?
Ein Optimizer kann m.E. nicht unterscheiden, ob ich über ein Count(*) nur wissen will, ob ein Datensatz da ist oder wirklich die Zahl haben will. Er kann nicht anders, als davon ausgehen, dass die korrekte Zahl benötigt wird.
Ob dann vorne dran noch ein Exists hängt oder was auch immer, geschenkt.

Neben der ganzen Tuning Diskussion bis jetzt, die sich "um die Spitze des Eisbergs" dreht, das Endergebnis von Count versus First usw. ist wahrscheinlich viel bedeutender, wie die Where Clause dahinter aussieht. Wenn das einigermaßen Index basiert durchläuft, ist es vermutlich irrelevant, ob ein Count=3 oder 15 rauskommt und ein First 1 statt dessen folglich 14 Indexzugriffe sparen täte.

Bei der Where Clause kann sich ein Optimizer prima austoben und ich behaupte mal, auch heute schadet notfalls etwas Analyse und ein paar Experimente nicht. Dass ein (auch moderner) Opensource Optimizer an MSSQL oder Oracle DB rankommt, wage ich allerdings zu bezweifeln.

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

Da ich aber die unterschiedlichen Varianten auch schon hier und da gehört hab, reizte es mich dann doch gerade
mal das mit geprüften Fakten zu bereichern.

Ergebnisse: Wenn eine "where xxx = ..." Bedingung mit 0 oder 1 Ergebnissen auf einem indizierten Feld benutzt wird, sind
alle Varianten (count(*), count(id), count(1), first 1) gleich schnell (siehe code beispiel unten)

Sobald die where Bedingung aber mehr als einen Datensatz liefert bzw Datensätze, die nicht auf einer Page
sind und man nur wissen muss das mindestens einer da ist oder nicht da ist, rechnet sich ein exists oder
insbesondere auch not exists sehr schnell, weil dann eben nicht weiter gesucht werden muss.

Die Datentypen selber haben aber auch indiziert erheblichen Einflus auf den speed

100000 randomsuche mit where indiziert auf bigint= ca 810 ms
100000 randomsuche mit where indiziert auf varchar(80) mit avg char_length 9= ca 1170 ms
100000 randomsuche mit where indiziert auf varchar(800) mit avg char_length 192= ca 4500 ms

Es gibt aber noch viel mehr Dinge, die man optimieren sollte, und teilweise sind die ganz
banal und erschreckend unlogisch, zB where Bedingung auf Feldern mit schlechter Selektvität,
Like in Prozeduren wenn parameter benutzt werden uvm.

Code:

execute block
as
declare variable i integer;
declare variable xx integer;
declare variable anz integer;
begin


  i=100000;
  while (i>0) do
  begin
    i=i-1;
    xx=rand()*100000;
    --v1  suchen über count(*)                 828 ms   812 ms 828 ms
    --select count(*) from test where id=:xx into anz;
    --v2  suchen über count(id)                813ms  813ms  813ms
    --select count(*) from test where id=:xx into anz;
    --v3  suchen über count(1)                 828 ms 828 ms 813ms
    --select count(1) from test where id=:xx into anz;
    --v4  suchen über first 1 id               797 ms 813 ms 812ms
    --select first 1 id from test where id=:xx into anz;
    --v5 suche über txt varchar(80) indiziert  1172 ms  1172 ms  1157 ms
    --select count(*) from test where txt='TXT2_'||:xx into anz;
    --v6 suche über txt2 varchar(800) indiziert  4531 ms  4421 ms  4422 ms
    --select count(*) from test where txt='TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx||'TXT2_'||:xx||:xx into anz;
  end
end


/*
CREATE TABLE TEST (
    ID    BIGINT NOT NULL,
    TXT   VARCHAR(80),
    TXT2  VARCHAR(800)
);

ALTER TABLE TEST ADD PRIMARY KEY (ID);

CREATE INDEX TEST_IDX1 ON TEST (TXT);
CREATE INDEX TEST_IDX2 ON TEST (TXT2);



Daten in der Tabelle

ID;TXT;TXT2
0;"TXT2_0";"TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00TXT2_00"
1;"TXT2_1";"TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11TXT2_11"
2;"TXT2_2";"TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22TXT2_22"
3;"TXT2_3";"TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33TXT2_33"
4;"TXT2_4";"TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44TXT2_44"
5;"TXT2_5";"TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55TXT2_55"
6;"TXT2_6";"TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66TXT2_66"
7;"TXT2_7";"TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77TXT2_77"
8;"TXT2_8";"TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88TXT2_88"
9;"TXT2_9";"TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99TXT2_99"
10;"TXT2_10";"TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010TXT2_1010"
11;"TXT2_11";"TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111TXT2_1111"
....
insgesamt 100000 records
....
99.997;"TXT2_99997";"TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997TXT2_9999799997"
99.998;"TXT2_99998";"TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998TXT2_9999899998"
99.999;"TXT2_99999";"TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999TXT2_9999999999"


*/

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

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