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ą.