*****************************************
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.
Kad tai suprasti, reikia tiesiog paziureti i sita selecta atidziau
SELECT * FROM `table` ORDER BY ID ASC LIMIT 1
galima paleisti kad ir 1000 transakciju tuo paciu metu su siuo selectu, 
visos jos ziures i viena ir ta pati id ir suformuos 1000 transakciju eile, 
todel ner ka dalinti... Tai puikiai iliustruoja mano prisegti pavyzdziai.
Jei dalinti id paralelinems transakcijoms, tai nebus 100% FIFO, nes nezinia 
kuri is dvieju (ar daugiau) paraleliai apdorojanciu skirtingus id 
transakciju, uzsibaigs pirma. Tai kontroliuoja MySQL dispatcheris su 
transaction managerio ir lock managerio pagalba. Nera jokiu garantiju to, 
kad ta transakcija kuri prasidejo pirma, uzsibaigs irgi pirma.