2x50 rašė:
> :) wow, genialu
>
> SELECT * FROM `table` ORDER BY ID ASC LIMIT 1
>
> problema yra sitam sakiny. Speju, kad migravus i InnoDB bus tas pats, o
> pridejus set transaction isolation level serializable bus katastrofa.

Nevisai. Problema yra iš esmės FIFO uždavinyje, o jam realizuoti 
SERIALIZABLE tinka. Katastrofa nenusimato dėl labai paprastos 
priežasties: pasikeis tik variklis, o veikimo principas liktų nepakitęs.
Net beveik neabejotinai nusimato paspartėjimas, nes InnoDB dirba 
efektyviau (tiek multi-core/multi-threaded, tiek sisteminiai dalykai: 
indeksai, rakinimas ir aibė kitų dalykų):
http://www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf



> Sitas sakinys efektyviai uztikrina, kad tuo paciu metu gali buti
> apdorojamas vienas ir tik vienas irasas. Idejus transakcijas (bet koks
> isolation level), transakcijos lygiai taip pat bus vykdomos po viena,
> todel kad visos transakcijos, kurios nores tuo paciu metu gauti
> duomenis, bandys gauti ta pati irasa. O serializable atveju pirma
> pasibaigs, o visos likusios, speju, gaus exceptiona - row does not exist
> arba cannot serialize transaction arba kazka panasaus, nes irasas, kurio
> jos visos laukia, jau nebeegzistuoja, ji istrins pirmoji transakcija...

Na, reikėtų nepamiršti, kaip ir kam tas serializable užtikrinamas... ;-)
O užtikrinamas lock'ais (taip, kad kitos transakcijos tiesiog lūkuriuos 
eilutėje; čia, suprantama, tada, kai rakinamas jau skaitymas).