[mysql]wat is sneller? grote query of meerdere kleine querys

[GeleFles]

ik heb een update query, die meerdere rijen gaat updaten.

dit kan ik op 2 manieren doen:

1 grote query:

UPDATE tabel SET waarde1=var1, waarde2=var2 WHERE waarde3=var3 OR waarde3=var4 OR waarde=var5 OR waarde3=var6.

of opdelen in kleine query's:
UPDATE tabel SET waarde1=var1, waarde2=var2 WHERE waarde3=var3 LIMIT 1
UPDATE tabel SET waarde1=var1, waarde2=var2 WHERE waarde3=var4 LIMIT 1
UPDATE tabel SET waarde1=var1, waarde2=var2 WHERE waarde3=var5 LIMIT 1
UPDATE tabel SET waarde1=var1, waarde2=var2 WHERE waarde3=var6 LIMIT 1

het aantal rijen dat geupdate moet worden is iedere keer verschillend, de eene keer zijn het er 2, maar het kunnen er ook een stuk of 40 zijn.

wat is verstandiger om te doen ivm de perfomance van de server??
het gaat hier dus om een windows server met php en mysql, en omdat hier ook nog redelijk wat andere serverapplicaties e.d. op draaien, wil ik het php en mysql zo licht mogelijk houden.

misschien dat het met mijn aantal rijen nog best meevalt, maar stel dat dit opschaalt naar 100+ in de toekomst, dan is het al wel verstandig om er rekening mee te houden.

[ Voor 19% gewijzigd door GeleFles op 14-10-2005 15:29 ]

[aex351]

in een while loop in combinatie met een array zou het wel mogelijk moeten zijn.

[LuCarD]

RonnieB82 schreef op vrijdag 14 oktober 2005 @ 15:27:
ik heb een update query, die meerdere rijen gaat updaten.

dit kan ik op 2 manieren doen:

1 grote query:

UPDATE tabel SET waarde1=waarde1, waarde2=waarde2 WHERE waarde3=bla OR waarde3=bla2 OR waarde=bla3 OR waarde3=bla4.

of opdelen in kleine query's:
UPDATE tabel SET waarde1=waarde1, waarde2=waarde2 WHERE waarde3=bla LIMIT 1
UPDATE tabel SET waarde1=waarde1, waarde2=waarde2 WHERE waarde3=bla2 LIMIT 1
UPDATE tabel SET waarde1=waarde1, waarde2=waarde2 WHERE waarde3=bla3 LIMIT 1
UPDATE tabel SET waarde1=waarde1, waarde2=waarde2 WHERE waarde3=bla4 LIMIT 1

het aantal rijen dat geupdate moet worden is iedere keer verschillend, de eene keer zijn het er 2, maar het kunnen er ook een stuk of 40 zijn.

wat is verstandiger om te doen ivm de perfomance van de server??
het gaat hier dus om een windows server met php en mysql, en omdat hier ook nog redelijk wat andere serverapplicaties e.d. op draaien, wil ik het php en mysql zo licht mogelijk houden.

misschien dat het met mijn aantal rijen nog best meevalt, maar stel dat dit opschaalt naar 100+ in de toekomst, dan is het al wel verstandig om er rekening mee te houden.

WHERE WAARDE3 IN ('bla','bla2','bla3') etc

[NMe]

Waarom maak je geen testcase om te kijken wat performanter is? Zoveel werk is het niet.

En aex351: PHP-code/een while loop eromheen bouwen lijkt me alleen maar trager.

[GeleFles]

-NMe- schreef op vrijdag 14 oktober 2005 @ 15:31:
Waarom maak je geen testcase om te kijken wat performanter is? Zoveel werk is het niet.

En aex351: PHP-code/een while loop eromheen bouwen lijkt me alleen maar trager.

hoe zou je zoiets kunnen maken dan??

de rijen die gewijzigd moeten worden komen uit een array, dus die worden vanuit die array in een sql query gegooid.
(en als je dan naar de multi-query manier zou gaan, dan zou je idd met een loop moeten gaan werken, hoewel ik dan voor een 'for' loop zou gaan)

[WouZz]

Agree with LuCarD. Het uitvoeren van meerdere queries is technisch gezien meer werk dan het evalueren van een OR contraint. Helemaal wanneer je PHP gebruikt en je applicatie zal moeten switchen tussen PHP en MySQL (tijdsverlies). De IN() operator optimaliseert de OR contraint binnnen MySQL en zal daardoor nog sneller werken.

[Verwijderd]

Ik neem aan dat dit een voorbeeld is en dat in werkelijkheid wat meer complexe querys gebruikt worden aangezien je je met de prefo. bezig moet gaan houden.


voordelen opbreken.

(A) je houd je code overzichtelijker en kan makkelijker een update toevoegen of verwijderen.

( Je kan een commit uitvoeren na elk update waardoor je de hoeveelheid data in je
rollback segment gelimiteerd houd. Ik weet niet hoe groot je update statements zullen worden maar dat kan in sommige situaties een redelijke overweging zijn.

(C) singel kleine calls naar de proc die na de commit weer worden gedropt en de processor weer vrij geven voor een eventueel ander proces.


Voordelen een grote query.

(A) proc. zal in een keer de complete query afhandelen en niet "eventueel" moeten wachten op proc time voor een opvolgende query wat wel het geval kan zijn als je hem in kleine stukjes opbreekt.

( Mogelijkheid om met een single rollback te werken zonder dat je met een safepoint zal moeten werken.


Onder de streep zou ik er voor gaan om verschillende kleine querys te maken ook al houd dit in dat je development time wat langer zal zijn,.... in een later stadium denk ik dat dit beter voor de beheersbaarheid en de performance zal zijn.