Abfrageproblem

[Bernd1984]

Hallo derfragende1979,

die Antwort von Biber2 ist die Grund für die längere Laufzeit, da erst alle Werte aus der Tabelle geholt werden und dann erst mit der WHERE-Bedingung eingeschränkt werden. Deshalb habe ich diesen Vorschlag auch garnicht erst gemacht.

Aber wenn du dir einen weniger komplizierten SQL durch längere Laufzeit und stärkere Belastung der DB dadurch erkaufen willst ist das auch ok.

Ich würde dir aber davon abraten, denn je mehr Datensätze du in der DB hast desto größer wird der Unterschied der Laufzeiten der beiden SQL's.

 

[derfragende79]

Was bedeutet denn der Wert in der Klammer? Der ist beim neuen Statement nämlich besser?

Grüße Chris

 

[Bernd1984]

Hallo Chris,

vllt. hilft dir das:
http://www.soebbi.de/blog/2008/11/10/zeitangaben-in-der-mysql-query-browser-statusleiste/

 

[derfragende79]

Vielen Dank Bernd,

Demnach ist aber das Statement von Biber2 schneller? Oder?

Grüße

 

[Biber2]

Moin derfragende,

Was bedeutet denn der Wert in der Klammer? Der ist beim neuen Statement nämlich besser?

Na ja, die Einstellung "Größer ist immer auch besser" ist eigentlich ein bisschen machohaft und trifft auch z.B. bei Bremswegen oder registrierten Straftaten pro 1000 Einwohner nicht zu.

vermutlich ist der Wert in Klammer ein (wie auch immer berechneter) Datendurchsatz im KByte/sec o.ä. Da wir die Result-Länge nicht kennen werden wir keine Kontrollrechnung durchziehen können.

Ansonsten kann ich mich nur Bernd1984 anschliessen mit einer Ergänzung.
Ja, es ist offensichtlich langsamer.
Falls aber die Geschwindigkeit nicht das einzige Kriterium ist, sondern auch die Wartbarkeit und die Flexibilität, dann könnte es trotzdem zu der Entscheidung führen, den von mir geposteten "inneren" SELECT als VIEW zu hinterlegen.
Dann wäre ein ein flexibler Zugriff auch mit Bedingungen "Where Lala > 12,7" oder ähnliches möglich, OHNE die Details der (komplexen Berechnungsformel) wissen zu müssen.

Wenn nur Du diese Abfrage im Sinne von schnelle Ad-hoc-Auswertung brauchst, dann bleibe bei der von Dir ursprünglich selbst geposteten Abfrage mit 2x den Rattenschwanz von (Berechnungsgeraffel) in der Query.

Interessehalber: wie ist denn das Größenordnungsverhältnis der Datensätze die gefunden werden im Vergleich zu allen?
Also die 67 DS sind gefiltert aus ? DS insgesamt?

Grüße
Biber

 

[derfragende79]

Dein Statement ist doch schneller, laut Bernds gepostetem Link zeigt die zweite Zeit die Bearbeitung am Server an und die Zählt meiner Meinung nach, weil ich das andere ne nicht wirklich beeinflussen kann.

Und vom größenverhältnis. Diese Berechnugng wird momentan über 500 Datensätze geführt. Es werden aber ziemlich sicher 4000 werden +/- 500 dort wird sichs irgendwo einpendeln. Definitiv wird es aber unter 10000 bleiben. Also eher ein kleines System

Grüße Chris

 

[derfragende79]

Ist das Statement mit dem Subselect nun schneller oder täusche ich mich?

Grüße

 

[Biber2]

Moin derfragende79 und Frohes Fest allen,

Ist das Statement mit dem Subselect nun schneller oder täusche ich mich?

Möglicherweise.

Ich denke, wenn Du tatsächlich in Richtung qualifizierter Vorhersagen kommen willst, dann wäre eine (kleine) Fleissarbeit von Dir vorher zu erbringen.

Unter der Annahme, dass ja nun zwangsweise egal mit welcher Strategie IMMER ein Full Select/nie ein IndexScan auf "deineTabelle" gemacht werden muss und auch die (komplexeBerechnung) für jeden Datensatz mindestens 1x durchgeführt werden muss, haben wir strategieunabhängig eine bestimmte Mindestdauer der Query, die nicht zu unterbieten ist.

Wenn die Hypothese also ist, das Zeitverhalten hängt ab von der Datensatzanzahl der letztendlich am Client bzw. im Resultset ankommenden Zeilen, dann...

Führe diese drei Fälle jeweils für die alte("deine") und neue("meine") Query durch

* Fall 1 Ohne echte WHERE-Clause: WHERE (komplexeBerechnung) > -4711--> alle 500 DS
* Fall 2: das Beispiel von oben mit seinem Resultset von 67 von 500 Sätzen
* Fall 3: ..WHERE (komplexeBerchnung) > 25 (damit nur kein oder ein Satz im RS ist)

Jeden dieser insgesamt 2 mal 3 = 6 Fälle 5x hintereinander abfeuern - am Besten mit einer gesetzten Query-Cachesize von 0Byte.

Dann wissen wir velleicht, ob wir jetzt Zufallswerte gesehen haben oder reproduzierbare/prognostizierbare Aussagen machen können.

Ich traue mir ohne diese Prüfung keine verbindliche Aussage zu "sinnvoller Optimierung" zu aufgrund von 2 Zeitwerten mit einem Wert in Klammern, über den die mySQL-Foren seit -zig Versionen spekulieren. Keine Ahnung, ob das Sekunden oder Kosten oder KB/sec sind.

Grüße
Biber