galima pabandyti kas bus jei isivesti dar indeksuota lauka kuris klientas 
pasieme irasa, ji indeksuoti ir daryti taip:
update `table` set client_id=my_client_id where client_id is null limit 1 ;
select * from `table` where client_id=my_client_id;
DELETE FROM `table` WHERE `ID` = (iš SELECT'o)

bent nereikes akivaizdziai paciam per tinkla locku deliot

"NicMC"  wrote in message news:jbnq7t$tvp$1@trimpas.omnitel.net...

On 2011.12.07 13:56, Laimis wrote:
> InnoDB. Isolation level Serializable. Ir papasakosi čia, kaip pasikeitė
> sparta.

Pagooglinau, pabandžiau, veikimo mechanizmas visiškai analogiškas, ar
bus nauda? Gal aš per daug noriu, bet pabandysiu paaiškinti dar kartą.

Kiekvienas klientas pasiima tik 1 įrašą šitaip:

LOCK WRITE
SELECT * FROM `table` ORDER BY ID ASC LIMIT 1
DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
UNLOCK

Esmė - nei vienas klientas neturi teisės gauti įrašo, kurį jau gavo
kitas. Taigi SELECT neturi grąžinti to įrašo. Row-level lockingas rakina
įrašus UPDEITUI, bet ne SELECTUI. Viskas puikiai sukosi ir su 300000
įrašų, kai buvo tik 20 klientų. Šiuo metu klientų jau beveik 50. Ir jau
prie 150000 įrašų prasideda bėdos.

OK, su InnoDB galima perrašyti taip:
BEGIN
SELECT * FROM `table` ORDER BY ID ASC LIMIT 1 FOR UPDATE
DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
COMMIT

O koks tolkas? Vis tiek likę klientai lauks...

Spėju, kad vis tik lieka keliai - hardware upgreidint / padaryti kažkokį
queue managerį, kuris iš DB selectintų daug, o jau paskui padalintų po
vieną.