vraagje over mysql_fetch_array

[megamuch]

eigenlijk een simpel performance vraagje..

Zoals u allen weet kun je met mysql_fetch_row/assoc/object etc dingen op roepen vanuit je mysql database...

Waar het mij even om gaat is het verschil tussen fetch_row en fetch_array en dan voornamelijk de laatste.

Ik wil namelijk wel eens weten wat er gebeurt als ik dit aanroep. Gooit mysql die gehele array in het geheugen? of is het alleen maar een manier om iets op een bepaalde manier aan te roepen?

De reden voor mijn vraag is dat ik op dit moment bezig ben met een groot aantal foto's in een database te stoppen. Die foto's komen in een blob field en ik wil graag weten of mysql mijn gehele select query (inclusief blob data) in het geheugen stopt en of dit met fetch_row op een andere manier gebeurt.

Het lijkt me namelijk nogal geheugen intensief om dit in 1 keer in het geheugen te stoppen.

Misschien gebeurt het bij geen van beide, dat kan natuurlijk ook, maar ik heb daar geen idee van en de mysql docs brengen me ook niet echt veel verder.

Iemand enig idee ?

hmm lees net ergens dat er geen verschil in zit..

* megamuch gaat benchmarken

beetje nutteloze post dit

[ Voor 6% gewijzigd door megamuch op 27-02-2003 01:19 ]

[supakeen]

http://www.php.net/manual/en/function.mysql-fetch-row.php
en
http://www.php.net/manual/en/function.mysql-fetch-array.php

Lees en vergelijk

[ACM]

megamuch schreef op 27 February 2003 @ 01:13:
Ik wil namelijk wel eens weten wat er gebeurt als ik dit aanroep. Gooit mysql die gehele array in het geheugen?

Ja, de mysql-library doet dat, je zult je php-process dus ook enorm zien groeien in geheugen als je veel data selecteerd. Ik weet niet precies, of het echt _alles_ probeert over te sturen, maar ik meende van wel.
Het is dus aan te bevelen de binaire fotodata, niet mee te selecteren als je het niet nodig hebt (voor de select * liefhebbers, weer een reden dat niet te doen en voor de mensen die denken dat mysql_num_rows hetzelfde doet als select count(* ) ook trouwens )

Het lijkt me namelijk nogal geheugen intensief om dit in 1 keer in het geheugen te stoppen.

Is het ook, maar met kleinere hoeveelheden data wel weer efficienter.

hmm lees net ergens dat er geen verschil in zit..

* megamuch gaat benchmarken

beetje nutteloze post dit

Nee, want het verschil tussen mysql_fetch_array/row/object heeft niets van doen met het in het geheugen plaatsen van het complete resultset...

Een aardig verschil is daarentegen wel dat fetch_array 2x zoveel geheugen nodig heeft als fetch_row, wat met foto's van 1MB best wat uitmaakt. Dit geldt echter wel alleen voor het resultaat van de functie, niet voor het complete resultset dus, maar die ene row.

[ Voor 12% gewijzigd door ACM op 27-02-2003 01:29 ]

[megamuch]

ACM schreef op 27 februari 2003 @ 01:27:
[nohtml]
[...]

Ja, de mysql-library doet dat, je zult je php-process dus ook enorm zien groeien in geheugen als je veel data selecteerd. Ik weet niet precies, of het echt _alles_ probeert over te sturen, maar ik meende van wel.
Het is dus aan te bevelen de binaire fotodata, niet mee te selecteren als je het niet nodig hebt (voor de select * liefhebbers, weer een reden dat niet te doen en voor de mensen die denken dat mysql_num_rows hetzelfde doet als select count(* ) ook trouwens )

wat is dan weer het verschil -performance wise- tussen deze twee geintjes? Ikzelf gebruik redelijk vaak num_rows maar als dat sneller cq efficienter/beter/sneller kan hoor ik het graag

(en dan bedoel ik geheugen/proc tijd/belasting mysql server etc )

count(*) en num rows dus he

[Jelmer]

megamuch, zie eerste 2 comments op http://www.php.net/manual/en/function.mysql-num-rows.php

[ Voor 7% gewijzigd door Jelmer op 27-02-2003 02:12 ]

[Soultaker]

Denk er wel aan dat je slechts een enkele rij in het geheugen laadt. Dat is doorgaans niet zo heel erg duur. Je wil die gegevens toch hebben, op de een of andere manier, anders zou je er met je query wel voor gezorgd hebben dat ze niet in je result set terecht kwamen. Je kunt dus zonder problemen fetch-row gebruiken.

In de C-API is het trouwens ook nog mogelijk om uitsluitend velden op te vragen. Dat kan in PHP (geloof ik) niet. Als het om een enkel BLOB veld gaat is dat ook niet interessant, aangezien de 'gewone' velden wegvallen tegen de enkele BLOB.

Mocht je nou echt meerdere BLOB-velden hebben en die apart uit willen lezen, dan zou je kunnen overwegen om een aparte query te doen voor elk veld. Je hebt dan wel wat extra overhead door het uitvoeren van de query, maar misschien cached MySQL dat wel, en zo niet, dan kan het misschien nog wel uit. Ik zou dit echter alleen doen als je daadwerkelijk problemen ondervindt met je huidige methode. Normaal gesproken hoort je operating system details als het alloceren van grote blokken geheugen af te handelen.

megamuch schreef op 27 February 2003 @ 02:03 n.a.v. het verschil tussen mysql_num_rows en SELECT COUNT(*):
wat is dan weer het verschil -performance wise- tussen deze twee geintjes? Ikzelf gebruik redelijk vaak num_rows maar als dat sneller cq efficienter/beter/sneller kan hoor ik het graag

(en dan bedoel ik geheugen/proc tijd/belasting mysql server etc )

count(*) en num rows dus he

In het eerste geval levert MySQL een enkele rij met een enkel veld op, met daarin een getal dat aangeeft hoeveel rijen er zijn. In het tweede geval gaat MySQL een result set aanmaken met daarin de inhoud van de hele tabel. Het opbouwen van de resultset zelf kost tijd; simpelweg een aantal dingen tellen is veel sneller dan het daadwerkelijk opleveren van die dingen (feitelijk de voorbereiding daarvan). Als het om een 'drukke' tabel gaat, moeten er misschien kopieën van gegevens gemaakt worden, omdat MySQL verwacht dat de gebruiker ze op gaat vragen. Als je dan 'alleen' een mysql_num_rows() call doet en daarna het resultaat opruimt, heeft MySQL op de achtergrond waarschijnlijk al een hoop werk voor niets gedaan!

Als je alleen maar het aantal resultaten nodig hebt, en niet geïnteresseerd bent in wat die resultaten nu precies zijn, dan kun je dat dus het beste direct zo aan MySQL vragen, met behulp van een COUNT(*) query.

[ Voor 8% gewijzigd door Soultaker op 27-02-2003 03:02 ]

[drm]

qua performance en gebruiksgemak is mysql_fetch_assoc () de beste. mysql_num_rows is nog een tikkie sneller, maar ik vind het persoonlijk toch wel errug fijn om velden met veldnaam aan te kunnen spreken