![]() |
AW: Select Count(*) vs. Select First 1
Zitat:
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? |
AW: Select Count(*) vs. Select First 1
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? |
AW: Select Count(*) vs. Select First 1
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" |
AW: Select Count(*) vs. Select First 1
Zitat:
Gruß K-H |
AW: Select Count(*) vs. Select First 1
@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. :-) |
AW: Select Count(*) vs. Select First 1
Hallo,
Microtuning?, den Begriff musste ich erst mal nachschlagen ;) Zitat:
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. |
AW: Select Count(*) vs. Select First 1
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:09 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz