In einigen Situation ist der geneigte Entwickler interessiert an der Gesamtzahl der Ergebnisse, die eine Abfrage ohne LIMIT – Klausel ergeben hätte. Die Holzhammermethode in so einem Fall ist, die Abfrage einfach nochmal ohne LIMIT abzufeuern. Doch es geht besser. Und zwar mit folgendem Konstrukt:
SELECT SQL_CALC_FOUND_ROWS productid, price, stock FROM products WHERE price > 100 LIMIT 10, 30; SELECT FOUND_ROWS();
Durch das „Einschleusen“ von SQL_CALC_FOUND_ROWS können wir direkt danach mit FOUND_ROWS() die Gesamtzahl an Ergebnissen erfragen. Für den Fall, dass nur ein Attribut selektiert werden soll, kann man auch direkt eine Abfrage draus machen:
SELECT SQL_CALC_FOUND_ROWS productid FROM products WHERE price > 100 LIMIT 10, 30 UNION SELECT FOUND_ROWS();
Auf die Art und Weise wird an das Resultset als letzte Zeile noch die Gesamtzahl an Ergebnissen ohne LIMIT angehangen. Mehr dazu direkt im MySQL Manual.
Zum Abschluss muss ich mich nochmal aufregen: Es gibt in MySQL keine Möglichkeit, alle Datensätze ab einem gewissen offset zu bekommen. Etwas verschämt schlägt das Handbuch vor, in solchen Fällen zu unschönen Konstrukten dieser Art zu greifen:
SELECT * FROM tbl LIMIT 95,18446744073709551615;
Mein Name ist
Pfiffig, hab ich so noch nie benutzt :-)
Kann aber zu abstürzen des MySQL-Servers führen laut http://phpperformance.de/sql_calc_found_rows-fuehrt-zu-unerklaerlichen-abstuerzen/
Sollte man also vorsichtig mit umgehen.
Zumindest die Kommentare dort machen einem Mut ;). Vielleicht ist das immerhin fast 3 Jahre alte Problem ja mittlerweile auch gelöst.
Hehe, hab gar nicht aufs Datum geachtet. Mir ist der Beitrag nur sofort eingefallen, als ich deinen Text gelesen habe. Müsste man mal gucken, wie es heute aussieht. Ich habe bislang nämlich auch auf die Methode mit SQL_CALC_FOUND_ROWS verzichtet, weil ich immer diese Abstürze im Hinterkopf hatte.
Scheint nicht so.
https://ckon.wordpress.com/2009/07/22/wordpress-still-uses-the-nasty-sql_calc_found_rows/
Allerdings ist mir auch nicht bekannt, dass WordPress Installationen massenweise abstürzen. *schulter-zuck*
Und wenn man das so liest fragt man sich, warum es SQL_CALC_FOUND_ROWS überhaupt gibt…
Dem Artikel kann ich entnehmen, dass bei der Verwendung von SQL_CALC_FOUND_ROWS keine Indexes verwendet werden (können).
Wenn man also eine Query ausführt, bei der keine Indexes verwendet werden können (warum auch immer), dann ist SQL_CALC_FOUND_ROWS auf jeden Fall eine sehr gute Alternative zum zweimaligen Ausführen der Query.
Sobald die Query allerdings Indexes nutzt, kann die Query besser zweimal ausführen und einmal mit COUNT(*).
Also zusammengefasst:
– nicht bei großen Tabellen, da evtl. Absturz
– nicht wirklich schneller bei where/order by
– Spart evtl. 2 Zeilen Code
hm … *denk*
Some time before, I needed to buy a car for my firm but I didn’t have enough money and could not purchase something. Thank God my sister suggested to try to get the home loans from reliable bank. Thence, I acted so and used to be happy with my auto loan.