Re: Limit und Rows

[Norbert Hartl <ruediger_(at)_penguins.de>]

On Thu, Apr 15, 1999 at 01:07:58PM +0200, Paul Schwarzl wrote:
> 
> 
> 
> 
> Paul Schwarzl wrote:
> >>
> >> Zuerst ein "select count(*) from..."  (ohne order by = langsam)
> >> ist dir als
> >> Lösung wahrscheinlich zu hässlich.?
> >>
> 
> Norbert Hartl wrote:
> > Der select ist doch selbst recht langsam, oder? Haesslich finde
> > ich das nicht :), allerdings denke ich, dass es sich auf die
> > Performance auswirkt. Ist doch so, oder?
> 
> Der Select count(*) ist sehr schnell wenn die Indexes stimmen. (Er gibt auch
> nur ein Feld zurück)
> 
> Ausserdem brauchst du Ihn nur einmal (zu beginn)
> 
> Anzahl=select count(*) from....
> select ... limit 40*seite,40....
> select ... limit 40*seite,40....
> select ... limit 40*seite,40....
> ....
> 
Nun, ich hab aber 1 Mio Datensatze und in einem mittleren schweren
Fall kostet es mich 6 Sekunden den count-query zu machen.
Ausserdem muesste ich fuer den Fall, den du meintest, die max.Anzahl
der Rows per CGI mitfuehren, da ein Weiterblaettern ja ein neuer
Skriptaufruf ist. Ansonsten muesste ich ihn jedesmal ausfuehren,
was bei wenig Aktivitaet auf dem DB-Rechner sehr schnell geht,
weil entweder der DB-cache oder der I/O-Cache greift.

> > Ich nehme dein Statement jedenfalls so hin, dass das was ich wollte,
> > nicht geht.
> 
> Würde ich nicht sagen. Nur, ich kenne limit bei mysql fast gar nicht. (Ich
> habe bei anderen DB´s sehr schlechte Erfahrungen mit limit gemacht und
> deshalb verdrängt).
Hmmm, ich mag es eigentlich auch nicht, aber es liegt so nahe, da
die Ressourcenschonung beim Speicher der Datenbank und die Bandbreiten-
schonung zwischen dem Db-Rechner und dem Webserver ein guter Grund
sind, es einzusetzen. Die Standardstrategie (die rows abzufragen)
liefert natuerlich nur die limitierte Anzahl.
> 
> Wie läuft das (bei mysql), wenn Datensätze zwischen deinen limit-selects
> gelöscht oder hinzugefügt werden, und das eine order by verschiebung ergeben
> müsste????
> 
> z.B. zeitlicher Ablauf:
> 1) Seite 1 (40 row) wird angezeigt
> 2) Datensätze dieser 40 rows werden gelöscht oder Datensätze werden
> eingefügt die nach order by Datensätze aus den ersten 40 verdrängen würden.
> 3) Seite 2 (40 row) wird angezeigt)
> was ist da drauf? wie zuverlässig ist das??
> 
In meinem Fall wuerden 40 Datensaetze durchs Raster fallen und wuerden
nicht angezeigt. Da ich keine Moeglichkeit sehe einen Cursor abzu-
speichern oder ein Resultset nach Aktualitaet zu ueberpruefen,
waere es ein Verlust. Ist fuer mich aber nicht wichtig, da die
Qualitaet des Services nur im minderen Masse davon abhaengt, ob sowas
passiert oder nicht. Ausserdem habe ich meine update-Geschichten
auf nachts verschoben, da ich dem locking aus zwei Gruenden (Verlangsamung
des Updates, Verlangsamung der Queries ) aus dem Weg gehen moechte.
Die Skripts sind nach neuen Erkenntnissen auch durchaus in der 
Lage waehrend eines Updates einen Deadlock zu erzeugen (und das alles
ohne transactions ;) )

Norbert

P.S.: Das mit den Indices habe ich jetzt kapiert und siehe da,
die Performance ist enorm. Ausserdem habe ich versucht, die
Datenbankgroesse zu optimieren und nun hat sie noch 20% der
alten Groesse *huestel*