Zitat von
generic:
ihr seit lustig. 13 sekunden zu lange ?
Ja! Reports sollen gefälligst schnell gehen. Und Alles, was nicht optimal ist, ist Schrott.
Es kommt doch immer auf die Menge der zu durchsuchenden Daten an. 13 Sekunden für ein Aggregat über 1.000.000 Records und diversen Joins ist ok, Aber wenn es nur ein paar Tausend Datensätze sind, dann stimmt da was nicht.
Zitat von
generic:
ich glaube nicht das es wert ist da sich noch stunden mit zu beschaeftigen.
Wenn man keine Ansprüche hat, nicht. Sonst schon.
Zitat von
generic:
aber wenn du unbedingt willst, dann lass dir die ausfuehrungsplaene anzeigen und optimiere dann anhand des plans die indizes.
btw. wenn ich statistiken ueber unsere webserver fahre (diese loggen in den
mssql-server) dauert die auswerten 45-60 minuten.
Hat
MySQL einen Optimizer? Kann man sich mit
MySQL den Execution Plan anschauen?
Erstmal: Sind die Indexe korrekt angelegt?
Ansonsten könnte man mit temporären Tabellen arbeiten. Das geht meistens schneller. Also im Grunde genommen das o.g. Konstrukt nehmen, die einzelnen Subselects in temporäre Tabellen packen und zum Schluss verwursten und die Temp-Dinger wieder wegschmeissen. Ich weiss nicht wieso, aber bei einigen
DBMS bringt das was (Vor Allen Dingen
MSSQL).
Ansonsten hilft nur eine redundante Summierungstabelle, die über Trigger (kann das
MySQL 
?) auf dem Laufenden hält. Das ist -nun ja- nicht die reine Lehre, aber in der Praxis Gang und Gäbe.