Welche Webapplikation nutzt es nicht. Das Blättern der Seiten.
<< 1 2 3 ... 8 9 >>
Hier könnt ihr gerne beitragen wie ihr das realisiert.
Die einfachste und daher auch von Anfänger am häufigsten verwendete Lösung ist es mit zwei Selects zu arbeiten.
Im ersten führt man das Query mit einem COUNT(*) aus und das zweite sorgt für die Anzeige mit LIMIT und OFFSET.
Hier werden die Queries aber doppelt ausgeführt... ist also nicht unbedingt die beste Wahl - gerade bei komplexen Queries.
Alternative1 ist es die Abfrage ohne LIMIT und OFFSET zu machen - also das gesamte Ergebnis zwischenzuspeichern (Storage Engine=MEMORY, Memcached, Filecache, ...) und auf dieser Teilmenge das Limit und Offset anzuwenden (das geht dann schnell). Das ist die beste Lösung wenn der Benutzer viel blättert.
In den meisten Szenarien blättern Benutzer sehr wenig und es wird unnötig viel Speicher-Overhead produziert.
Alternative2 ist das Schlüsselwort SQL_CALC_FOUND_ROWS (dev.mysql.com/doc/refman/5.1/de/information-functions.html). Man setzt es nach dem SELECT ein und benutzt nur die Query Abfrage mit LIMIT und OFFSET. Um die Anzahl der tatsächlichen Ergebnisse zu erhalten fragt man den Cache mit SELECT FOUND_ROWS() ab.
Das ist für die meisten Szenarien die beste Möglichkeit. Allerdings gibt es bei komplexen Queries manchmal Probleme. Siehe Bugreport (bugs.mysql.com/bug.php?id=18454)
Alternative3 bietet eine kleine Einschränkung des Benutzerverhaltens. Oftmals würde der Benutzer niemals auf Seite 3 springen, wenn er Seite 2 noch nicht gesehen hat. Warum also nicht einfach mit einem simplen ">> next" Button arbeiten? Um zu erfahren ob man nun auf der letzten Seite ist fragt man immer 11 statt 10 Ergebnisse ab. Und falls der 11te Wert vorhanden ist, wird der Button angezeigt. Für komplexe Queries hat sich das für mich als die beste Lösung herausgestellt.
Alternative4 wird angeblich auch von Google genutzt. Wer schon viele Queries optimiert hat, kennt die Schätzungen des MySQL Query Optimizers. Sie sind nicht sehr genau, aber sie zeigen den Weg. Die Anzahl an Ergebnissen wird also geschätzt indem eine zweite Abfrage mit EXPLAIN ausgeführt wird. Natürlich kann es sein, dass man nicht alle Ergebnisse erhält, oder dass man mehr Seiten dargestellt bekommt, als es tatsächlich gibt, aber es ist eine gute Näherung die man nur gut behandeln muss. Wenn es also nicht um exakte Werte geht (in den meisten Szenarien geht es um exakte Werte), dann sollte man diesen Weg nehmen.
Literatur:
mysqlperformanceblog.com/2008/…imize-paginated-displays/
<< 1 2 3 ... 8 9 >>
Hier könnt ihr gerne beitragen wie ihr das realisiert.
Die einfachste und daher auch von Anfänger am häufigsten verwendete Lösung ist es mit zwei Selects zu arbeiten.
Im ersten führt man das Query mit einem COUNT(*) aus und das zweite sorgt für die Anzeige mit LIMIT und OFFSET.
Hier werden die Queries aber doppelt ausgeführt... ist also nicht unbedingt die beste Wahl - gerade bei komplexen Queries.
Alternative1 ist es die Abfrage ohne LIMIT und OFFSET zu machen - also das gesamte Ergebnis zwischenzuspeichern (Storage Engine=MEMORY, Memcached, Filecache, ...) und auf dieser Teilmenge das Limit und Offset anzuwenden (das geht dann schnell). Das ist die beste Lösung wenn der Benutzer viel blättert.
In den meisten Szenarien blättern Benutzer sehr wenig und es wird unnötig viel Speicher-Overhead produziert.
Alternative2 ist das Schlüsselwort SQL_CALC_FOUND_ROWS (dev.mysql.com/doc/refman/5.1/de/information-functions.html). Man setzt es nach dem SELECT ein und benutzt nur die Query Abfrage mit LIMIT und OFFSET. Um die Anzahl der tatsächlichen Ergebnisse zu erhalten fragt man den Cache mit SELECT FOUND_ROWS() ab.
Das ist für die meisten Szenarien die beste Möglichkeit. Allerdings gibt es bei komplexen Queries manchmal Probleme. Siehe Bugreport (bugs.mysql.com/bug.php?id=18454)
Alternative3 bietet eine kleine Einschränkung des Benutzerverhaltens. Oftmals würde der Benutzer niemals auf Seite 3 springen, wenn er Seite 2 noch nicht gesehen hat. Warum also nicht einfach mit einem simplen ">> next" Button arbeiten? Um zu erfahren ob man nun auf der letzten Seite ist fragt man immer 11 statt 10 Ergebnisse ab. Und falls der 11te Wert vorhanden ist, wird der Button angezeigt. Für komplexe Queries hat sich das für mich als die beste Lösung herausgestellt.
Alternative4 wird angeblich auch von Google genutzt. Wer schon viele Queries optimiert hat, kennt die Schätzungen des MySQL Query Optimizers. Sie sind nicht sehr genau, aber sie zeigen den Weg. Die Anzahl an Ergebnissen wird also geschätzt indem eine zweite Abfrage mit EXPLAIN ausgeführt wird. Natürlich kann es sein, dass man nicht alle Ergebnisse erhält, oder dass man mehr Seiten dargestellt bekommt, als es tatsächlich gibt, aber es ist eine gute Näherung die man nur gut behandeln muss. Wenn es also nicht um exakte Werte geht (in den meisten Szenarien geht es um exakte Werte), dann sollte man diesen Weg nehmen.
Literatur:
mysqlperformanceblog.com/2008/…imize-paginated-displays/