[MySQL] Snel vinden result count v/e query

[hobbit_be]

Ik develop op mySQL v4.0.0+ en deze kent SQL_CALCULATE_ROWS en LAST_ROWS() functie.

Helaas heeft onze provider een 3.22.x.

Nu vroeg ik me af hoe ik het snelst aan het aantal rows kan geraken zonder de data door te pompen.

mysql_num_rows() lijkt me erg traag?

[Grijze Vos]

het aantal rijen in een tabel, of wat?

SELECT COUNT(ID); ofzo?

Geef wat duidelijker aan wat je wil...

[hobbit_be]

stel je hebt query "X" (dit kan echt alles zijn dus ook met INNER/LEFT/etc).
je krijgt dus een "tabel" terug.
Deze tabel kan Y-aantal lang zijn.
Ik wil echter steeds maar Z-aantal zien. (Enter "LIMIT")
Om de UI steeds logisch te houden moet ik weten (ivm Next/Prev/First/Last) hoeveel er in totaal zijn. Met MYSQL v4.0 doet ie dat zonder de data op te slaan (locaal) dus gaat dat vele malen sneller dan eerst de query doen en dan nog een dezelfde met Limit.

Ik ben nu aan het zien aangezien het snel moest gaan dat ik dezelfde query kan gebruiken door in de result set te "jumpen" )in JDBC is dit standaard, nu nog zien of het met PHP ook gaat).

[ACM]

De resultset wordt (bij mysql) altijd naar de client gestuurd, ongeacht of je erin jumpt of niet. Dus daar zal je nauwelijks winst uit halen.

Er zijn iig twee manieren, voor zover ik zie:
- Doe eerst een `select count( * ) ... jouw query` en gebruik dat resultaat voor de hoeveelheid, en doe daarna jouw originele query. Dit zou niet eens zo heel veel slomer moeten zijn dan het gebruik van SQL_CALCULATE_ROWS

- Hou het resultaat van de query-count bij in een of andere tabel of een speciaal veldje, bijv hier op got worden in de topicstabel het aantal reacties bijgehouden. Niet supernetjes of veilig (zeker met mysql's gebrek aan functions/triggers/e.a.), wel heel snel.

[hobbit_be]

wat bedoel je met de resultset wordt altijd teruggestuurd? Ik neem toch aan dat ie per

mysql_fetch_row() dan pas het resultaat gaat doorpompen van mysql->php. Want waarom zou er anders een unbuffered query opzitten?

om die count zelf bij te houden - tja dat gaat niet echt lukken want aangezien al die tabellen linked zijn kan de verandering in een ook de resultcount compleet veranderen van een bepaalde query.

Na wat meer lezen zag ik dat ik de pointer zelf kan zetten zodat ik gewoon de query volledig uitvoer (maakt dan toch amper iets uit) en dan gewoon de pointer zetten naar de juiste plek (ie ik doe de "limit" dan zelf). Zo is er maar 1 query waarvan de CPU tijd best wel hoog gaat liggen (hoger dan met limit) maar sneller dan hem 2 keer uitvoeren. Dat ie dan de resultset in het geheugen moet gooien is dan maar zo.

De "view" is een heel generieke sortable / searchable view van linked data.

Wat doet een "echte" ( ) SQL server in zo'n geval?

[ACM]

Met "het hele resultset wordt overgestuurd" bedoel ik precies dat.
Mysql formuleert een resultset a.d.h.v. een query en stuurt die door naar de client, geen gedoe met "per call een result oversturen" etc (ik moet er niet aan denken dat elke fetch-call een netwerkcall zou zijn ).

Afhankelijk van wat je precies doet en de grootte van je resultset zal het wel degelijk sneller zijn om een losse count-query en een losse data-fetch-query uit te voeren, bij een resultset van bijvoorbeeld zo'n 50000 records van elk 1KB zou er dan 50MB aan data overgestuurd moeten worden...

En ik weet niet wat een "echte" sql-rdbms doet in zo'n geval, sommige sturen de data door per brok van X records/bytes, anderen sturen alles door.
Sommige bieden je cursors aan door je resultsets, die je dan over verschillende webpages kan hergebruiken. Maar ook die zijn niet perse heel handig, aangezien dat weer erg veel sql-server-sided resources kost, zeker bij webpages waarvan je geen garantie hebt dat er nog wel een vervolgrequest komt...

[hobbit_be]

jikes!

beetje angstaanjagend eigenlijk. Begin te snappen waarom jullie "fake" counts bijhouden dan. (je begrijpt wat ik wil zeggen).

Nu heb ik in ieder geval wat opties - maandag op het werk zal ik hem wat fake data invoegen om te zien wat het pratisch het beste werkt (ie: normaal is het een "site" die maar door 1 / 2 mensen at the same time word gebruikt).

Ik geloof dat ASPX ook alles doorgeeft waarna je met de data nog "locaal" kunt gaan spelen.

op GoT hebben jullie vast een paar servers voor het forum?

[ripexx]

Je counts bijhouden is op een druk bezochte site eigenlijk een must. Om bij iedere view van een index of topic overzicht een aantal counts te gaan uitvoeren is technische gezien niet zo'n probleem. Volgens het normaliseren zou je het ook gewoon niet doen, maar preformance gaat in bijna alle gevallen voor een correct theoretisch datamodel.

offtopic:
GoT heeft trouwens een DB server en T.net en Got samen heebn 4 webservers in gebruik

[Grijze Vos]

Nu is de count zonder een where clause triviaal (DB cached die waardes). Maar de meeste counts die je bij bijvoorbeeld een forum moet doen, hebben toch al snel een where clause. En die data bijhouden is dan niet meer dan logisch..