Zitat Zitat von Robi Beitrag anzeigen
wenn ich den
having max(dadate) >= (current_date - (select mon from xx) Months)),
durch eine
where dadate >= (current_date - (select mon from xx) Months)

ersetze
verdoppelt sich die Laufzeit, das bringt also nix
Bei der HAVING ... Version wird er zunächst mal einen passenden Index basierend auf die Key-Felder im WHERE suchen und den Filter des HAVINGs erst mit den Ergebnissen der davor ermittelten Sätze umsetzen.

Wenn du das HAVING ins WHERE rein stellst und die Indices ... sagen wir mal "Sub-Optimal" sind, kann es durch einen schlechten Index sogar langsamer sein.

Aber wenn ich die empfohlenen LF lösche!!! bin ich 20-35 Sekunden schneller!
Wie kann das sein???
Das ist einer von vielen Grund warum ich den Index-Advisor nicht empfehlen kann.
Ein falscher Index der zwar auf die Key-Felder super passt, wo aber andere Auswahlkritieren nicht übereinstimmen, kann es schon passieren, dass die DB zickt und sagt:
"So a schaß, nichts ist so wie ichs gern hätt, ich geh lieber zu fuß" --> Table Scan
Mit solchen Problemen hab ich auch schon öfters zu tun gehabt.

Lösung: die Queries aufteilt in mehere Sub-Queries, für die entsprechende Indices angelegt werden.
Und WHERE Bedingungen die einen Table-Scan auslösen würde bzw. die auch bei einem Index viel Zeit verbraten (erkennst du im Visual Explain), in die oberste Ebene verschieben.

Damit habe ich schon einige Queries wo mit kombinationen von LIKE, MAX, ORDER BY usw. eine extrem schlechte Performance hatten, wieder in die millisek. bereich bringen konnte.

lg Andreas