[mysql] update timestamp tijdens select limit 1

[scubapro]

Ik heb een db met x.xxx.xxx records. Ieder record heeft een timestamp. Ik voer 2 queries achter elkaar uit.

SELECT * FROM tabel ORDER BY timestamp ASC LIMIT 1

Ik krijg dus de oudste record terug. Daarna doe ik

UPDATE tabel SET timestamp = CURRENT_TIMESTAMP WHERE id = id_van_select

Nu wordt het script zo snel achter elkaar uitgevoerd dat er meerdere keren hetzelfde record geselecteerd wordt. Dus voordat de update query verwerkt is wordt de select meerdere keren uitgevoerd.

Hoe kan ik voorkomen dat er meerdere keren hetzelfde record geselecteerd wordt. Ik zoek dus eigenlijk een update van de timestamp tijdens de select of iets wat het record tijdelijk locked.

[Janoz]

Transacties, eventueel met pessimistic locking. Je zou echter ook kunnen kijken of je je aanroepende proces slimmer kunt maken zodat hij niet als een dolle probeert hetzelfde record te verwerken.

[Gomez12]

Waarom 2 queries? Waarom niet gewoon het in 1 stoppen? Dan heb je 99% van het probleem niet meer.

[GlowMouse]

Gomez12 schreef op vrijdag 06 februari 2015 @ 16:26:
Waarom 2 queries? Waarom niet gewoon het in 1 stoppen? Dan heb je 99% van het probleem niet meer.

Dit. Als het voor een queue is, kun je het geüpdatete record achterhalen mbv een extra variabele of LAST_INSERT_ID(): http://stackoverflow.com/...last-updated-row-in-mysql

[scubapro]

GlowMouse schreef op vrijdag 06 februari 2015 @ 16:29:
[...]

Dit. Als het voor een queue is, kun je het geüpdatete record achterhalen mbv een extra variabele of LAST_INSERT_ID(): http://stackoverflow.com/...last-updated-row-in-mysql

Ik zou het best in 1 query willen stoppen maar hoe kun je in een select query een update van de timestamp verwerken? De eerste query is een select. Geen insert of update.

Omdat het php script vanaf verschillende kanten aangeroepen wordt kan ik in php niets regelen. Het moet in MySQL. Vandaar de timestamp. Maar het probleem ontstaat dus wanneer er voor de update van de timestamp door request 1 een select gestart wordt door request 2 (of 3, 4 enz)

De queries voer ik al direct achter elkaar uit.

[GlowMouse]

scubapro schreef op vrijdag 06 februari 2015 @ 19:01:
[...]


Ik zou het best in 1 query willen stoppen maar hoe kun je in een select query een update van de timestamp verwerken? De eerste query is een select. Geen insert of update.

Je kunt je UPDATE een ORDER BY en een LIMIT meegeven. Daarmee update je de juiste rij zonder eerst een SELECT uit te voeren. Daarna heb je nog een extra query nodig als je wilt weten welke rij je hebt geüpdatet.

De queries voer ik al direct achter elkaar uit.

'Direct achter elkaar' is blijkbaar niet snel genoeg, omdat een ander proces tussentijds hetzelfde record kan selecteren. De beste oplossing hiervoor is de UPDATE-query te wijzigen. Transacties werken ook, maar als je die kunt vermijden is dat alleen maar mooi meegenomen omdat je met transacties weer goed moet uitkijken voor andere problemen.

[pedorus]

Die select kun je toch omschrijven in de update? update ondersteund ook order by en limit 1
Het goede voorbeeld lijkt mij http://stackoverflow.com/a/9932809 en dan ipv where doe je ORDER BY timestamp ASC LIMIT 1

(te laat, dubbel)

Ik vraag me trouwens af welk probleem je aan het oplossen bent, en of daar geen betere oplossing voor is dan een bepaalde tabel steeds updaten. Bijvoorbeeld een tellertje atomisch laten oplopen en id = (tellertje mod [aantal ids]) selecteren.

[cariolive23]

Gebruik een transactie, wat toch al een goed gebruik is, en vervolgens een SELECT ... FOR UPDATE om het gevonden record te locken.

[scubapro]

Bedankt. Ik heb het opgelost met een query als:

SET @naam := '';
UPDATE tabel SET timestamp = CURRENT_TIMESTAMP, naam = (SELECT @naam := naam)
ORDER BY laatste_controle ASC LIMIT 1;
SELECT @naam;

Hij is niet heel snel. Duurt gem rond de 3 seconden maar er worden geen dubbele records meer gebruikt.

[GlowMouse]

scubapro schreef op maandag 09 februari 2015 @ 13:50:
Bedankt. Ik heb het opgelost met een query als:

SET @naam := '';
UPDATE tabel SET timestamp = CURRENT_TIMESTAMP, naam = (SELECT @naam := naam)
ORDER BY laatste_controle ASC LIMIT 1;
SELECT @naam;

Hij is niet heel snel. Duurt gem rond de 3 seconden maar er worden geen dubbele records meer gebruikt.

Het zou veel sneller kunnen met InnoDb (als concurrenty een probleem is) en een index op laatste_controle.