Re: Performance von LIMIT und OFFSET

Hi,

-- Andreas Seltenreich <seltenreich(at)gmx(dot)de> wrote:

> "die aufzulösen sind" hört sich allerdings schwer nach Joins an.

ups, das ist wohl war ...
Ich bin gerade MySQL-Kollegen-Verseucht, und da kriegt man immer wieder gerne
seltsame Geschichten zu hören ("Referential Integrity ist zu langsam und das
brauchen wir nicht") ;-)

> Es gibt gute Gründe gegen einen Cursor. Wenn z.B. der User via CGI
> blättert, müßte man einen ziemlichen Aufwand betreiben, um einen
> Cursor nutzen zu können. Bei einer gemeinen Verbindung schreit
> blättern aber geradezu nach einem Cursor.
>
> Gut möglich, daß bei einer passenden Abfrage subjektiv kein
> Unterschied festgestellt wird; trotzdem wird unnötig Rechenzeit
> verbraten.

die Frage ist natürlich, ob es mehrere SELECTs mit unterschiedlichen Offsets
gibt oder immer nur einen; dann bringt auch ein Cursor nichts.

Bei ein paar tausend Datensätzen könnte es auch effizient sein, sich alle
oder viele zu holen und sie manuell zu bearbeiten -- wenn mehrfacher Zugriff
auf die Daten gewünscht ist.

Ansonsten könnte es zudem die Möglichkeit geben, die entsprechende
Sortierreihenfolge (Position) als extra Spalte mitlaufen zu lassen, darauf
einen Index zu setzen und danach zu selektieren. Wenn sich die Reihenfolge
nicht ändert und nur hinten was hinzu kommt ist das wohl das beste; wenn
sich nur relativ selten was an der Reihenfolge ändert könnte es immer noch
schneller sein, hin und wieder ein Update auf die Sortier-Spalte zu machen ...

Ciao
Alvar

--
Alvar C.H. Freude -- http://alvar.a-blast.org/
http://odem.org/
http://www.assoziations-blaster.de/info/Hommingberger-Gepardenforelle.html
http://www.assoziations-blaster.de/