Mailinglisten-Archive |
Hallo Norbert, Norbert Pfeiffer wrote: > bei der Arbeit mit Limit ist der Zeitfaktor sehr hinderlich. > Kein User blaettert alle Resultate durch, aber Bots kennen > keine Gnade, z.B. hatten wir das Stichwort 'Liebe' verlinkt, > und die Bots haben alle dreitausend Treffer in 10-er Schritten > abgefragt. Dabei haben wir festgestellt, dass Limit zwar am > Beginn sehr fix ist, aber bei hoeheren Seiten grausam lahmt. Das hatten wir 2004 schonmal: http://lists.phpbar.de/pipermail/php/Week-of-Mon-20041213/014874.html "Was ich jedoch festgestellt habe ist: Mit wachsendem Offset braucht jede Datenbank mehr Zeit. z.B. LIMIT 0,10 geht fix, LIMIT 300,10 dauert laenger und bei LIMIT 3000,10 brauchts einen Kaffeeautomaten ..." Zwei Queries lassen sich nicht vermeiden, aber ein LIMIT sollte nicht so langsam sein. Hab das ganze hier mal auf einer Tabelle mit > 100t Einträgen laufen lassen. Nach jeweils einem "service mysqld restart" bringt es folgende Werte zu Tage: count(*), 24987 rows, 0.7sec select * from foobar where var2 = '$string mit 64 zeichen' limit 10556,10; 0.24sec Und mit dem Query Cache ist das sowieso kein Problem mehr: set global QUERY_CACHE_SIZE=(16*1024*1024). mysql> show status like 'qcache_hits'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Qcache_hits | 1 | Oder halt einfach die einzelnen Seiten mit z.B. memcache zwischenspeichern. Gruss, Martin
php::bar PHP Wiki - Listenarchive