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

Ziuriu, kad mes kalbam apie skirtingus dalykus.
Tai, ka as bandau pasakyt yra, kad
"InnoDB. Isolation level Serializable. Ir papasakosi čia, kaip pasikeitė
sparta."
be papildomu pakeitimu yra nepakankamas tam, kad is esmes pagerinti 
greitaveika.
O pats man irodineji, kad
"Keletas minčių dėl konkurentiškumo. Galima būtų pabandyti realizuoti taip:
Pasirašyti trigerį, kuris kas tam tikrą laiką išrinktų iš tos sąlyginai
didelės lentelės į atskirą lentelę (kuri, beje, gali būti in memory)
eilinę ID porciją (kokį šimtuką-tūkstantuką, priklausomai nuo to, kaip
sparčiai valgoma ta eilė)."
veiks gerokai greiciau.

Tai, kad as tam ir nepriestarauju, atvirksciai, is to ka rasau ir turi 
susidaryti ispudis, kad taip ir reiketu daryti, turint omeniu, kad nebus 
100% FIFO...
Viskas, ka rasiau auksciau, yra apie tai, kaip butu jei nedaryti "Pasirašyti 
trigerį, kuris kas tam tikrą laiką išrinktų iš tos sąlyginai
didelės lentelės į atskirą lentelę", o palikti taip kaip yra, tiesiog 
pramigravus is MyISAM i InnoDB (zinoma be write lock komandos)
:)