Hallo ursus, als ich das Problem dem [Stapelüberlauf meines Vertrauens](https://stackoverflow.com/questions/186588/which-is-fastest-select-sql-calc-found-rows-from-table-or-select-count) vorgelegt habe, fand ich heraus, dass es noch schlimmer ist: offenbar ist Oracle von dieser Idee nicht (mehr) überzeugt. Bei MariaDB steht es nicht. [Keyword und Funktion sind seit MySQL 8.017 missbilligt und auf der Roten Liste](https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_found-rows). Was die Maria daraus macht, ist natürlich eine andere Frage, aber vermutlich Also Bernd: Mach weiter mit COUNT. Ein Index auf a_katId, der ggf. noch a_status an letzter Stelle mit einschließt, dürfte dann zum besten und zukunftssichersten Ergebnis führen. Edit: Ach verdammt, das schmökere ich bei MariaDB rum und Dedlfix überholt mich rechts :) _Rolf_ -- sumpsi - posui - clusi

Hallo ursus, als ich das Problem dem [Stapelüberlauf meines Vertrauens](https://stackoverflow.com/questions/186588/which-is-fastest-select-sql-calc-found-rows-from-table-or-select-count) vorgelegt habe, fand ich heraus, dass es noch schlimmer ist: offenbar ist Oracle von dieser Idee nicht (mehr) überzeugt. Bei MariaDB steht es nicht. [Keyword und Funktion sind seit MySQL 8.017 missbilligt und auf der Roten Liste](https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_found-rows). Was die Maria daraus macht, ist natürlich eine andere Frage, aber vermutlich Also Bernd: Mach weiter mit COUNT. Ein Index auf a_katId, der ggf. noch a_status an letzter Stelle mit einschließt, dürfte dann zum besten und zukunftssichersten Ergebnis führen. _Rolf_ -- sumpsi - posui - clusi