2x50 rašė:
> *****************************************
> Jei skaitytum atidžiau, tai pastebėtum, kad siūlyti būdai, kaip
> transakcijos dalinasi/rezervuojasi id (tas pats FOR UPDATE), po ko
> vyksta konkurentiškas/lygiagretus tolimesnis apdorojimas (nebekalbant
> apie tai, kad MyISAM atveju, kai kiekvienas modifikuojantis DMLS'as
> užrakina visą lentą, tai iš principo neįmanoma). Todėl greitaveika bus
> gerokai didesnė, nes aibės transakcijų, pasidalinusios id prie durų,
> toliau tęs darbą (tikėtina imlesnį resursams) lygiagrečiai.
> *****************************************
>
> Va kur yra tamstos klaida, mano manymu.
> Transakcijos id prie duru nepasidalins, ir nebus jokiu lygiagreciu
> nekonfliktuojanciu transakciju. Bus arba po viena be konfliktu (pridejus
> FOR UPDATE) arba lygiagreciai ir visos tarpusavyje konfliktuojancios, is
> kuriu tik viena vienintele atliks realu darba, likusios tik valgys
> resursus.

Na, žiū, pavyzdys:

Transkacijos, tarkime, savo darbą padaro per kokią 1 ms.
Sušoka 100 konfliktuojančių ir laukia eilėje besidalindamos id paprastu 
sakiniu; ar Audrys pasiūlytu būdu, ar mano (kai pirma atskiroje 
lentelėje bandoma rezervuoti UPDATE'u, o vėliau pasitikrinama; tai iš 
esmės analogiškas būdas). Tas pasidalijimas veikiausiai įvyksta per 
milisekundės dalis, o toliau jau, visas 100 transakcijų, gavusios savo 
id gali vykti lygiagrečiai/konkuruojančiai (skaityti iš db, trinti 
įrašus). Tai ir yra tas tavo minėtas „beveik lygiagrečiai“ būdas.