MySQL Limit: Anzahl Ergebnisse ohne LIMIT herausfinden

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;

Weitere Posts:

Dieser Beitrag wurde unter Datenbanken, Quicktips, webdev veröffentlicht. Setze ein Lesezeichen auf den Permalink.

9 Antworten auf MySQL Limit: Anzahl Ergebnisse ohne LIMIT herausfinden

  1. Oliver sagt:

    Pfiffig, hab ich so noch nie benutzt :-)

  2. digilist sagt:

    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.

    • david sagt:

      Zumindest die Kommentare dort machen einem Mut ;). Vielleicht ist das immerhin fast 3 Jahre alte Problem ja mittlerweile auch gelöst.

      • digilist sagt:

        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.

      • Oliver sagt:

        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*

        • david sagt:

          Und wenn man das so liest fragt man sich, warum es SQL_CALC_FOUND_ROWS überhaupt gibt…

          • digilist sagt:

            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(*).

          • Oliver sagt:

            Also zusammengefasst:
            – nicht bei großen Tabellen, da evtl. Absturz
            – nicht wirklich schneller bei where/order by
            – Spart evtl. 2 Zeilen Code

            hm … *denk*

  3. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.