Select Count(*) vs. Select First 1

[hoika]

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?

[jobo]

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.

[ConnorMcLeod]

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

Delphi-Quellcode:

select 
  count(1) RecCount
from 
  t_tabelle
;

[Bernhard Geyer]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1372607)

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

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

[ConnorMcLeod]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1372609)

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

Delphi-Quellcode:

while not eof do next

natürlich...

[Blup]

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

[jobo]

Zitat:

Zitat von Blup (Beitrag 1372611)

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

Gleich schnell wie was?

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

Zitat von hoika (Beitrag 1372617)

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:

Zitat von hoika (Beitrag 1372658)

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.

[p80286]

Zitat:

Zitat von hoika (Beitrag 1372597)

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.

[IBExpert]

Zitat:

Zitat von TigerLilly (Beitrag 1372668)

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"


*/

[IBExpert]

Zitat:

Zitat von p80286 (Beitrag 1372688)

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.

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

[TigerLilly]

Zitat:

Zitat von IBExpert (Beitrag 1372691)

Zitat:

Zitat von TigerLilly (Beitrag 1372668)

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. 8-)

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:

Zitat von IBExpert (Beitrag 1372696)

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:

Zitat von hoika (Beitrag 1372805)

...

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.