> Aš suprantu, kad tikrai norima didesnės spartos, nes MyISAM jau stabdo.
> Vienas paspartėjimas beveik garantuotai nusimato, jei bukai pereiti prie
> InnoDB (čia jau į temą SERIALIZABLE ir/ar FOR UPDATE būdai, kas
> simuliuotų MyISAM veikimą). Ar galėtum suabejoti šiuo teiginiu, jį
> sukritikuoti, turint omenyje tą patį hw, InnoDB 1.1 (MySQL 5.5)?

A velnias žino, jeigu MyISAM variantas daro LOCK TABLE, tai analogiškas 
variantas bus toks pat blogas - nes laiko lock'ą interaktyviai (nebent 
SP tai daro, tada truputuką geriau ir InnoDB turi galimybę greičiau veikt).

Esmė ta, kad nei InnoDB nei MyISAM atveju konkurentiškumo tame nėra, tad 
čia optimizuojama neitin teisingoje vietoje.

> Kitas paspartinimo momentas/etapas, jau perėjus prie InnoDB, būtų
> konkurentiškumo įvedimas (Audrys būdas ar mano siūlytas, nors jis ir
> nėra optimalus), jei tik tai nėra griežtas FIFO.

Pagal originalią salygą tas metodas puikiai tinka, nes ten lenta 
atlockinama prieš pradedant darbą - tad panašu, kad nesvarbu, kad pats 
didelis eilės apdorojimo procesas būtų užbaigtas laiku, bile tik ID 
išduoti normalia eilės tvarka.

> Tai lock'o suteikimo tvarka ir nesiremiama; remiamasi tuo, kad lock'as
> jau suteiktas ir transakcijos persidengiančiai išsirikiuoja: T1, T2, T3,
> ..., Tn ir tam tikru momentu jos vyksta lygiagrečiai/konkurentiškai,
> todėl tikrasis/griežtasis FIFO principas pažeidžiamas jau ir šiuo
> aspektu, jei DBMS negarantuoja tokios pačios jų užbaigimo sekos. Juk
> negarantuoja? (aibė multi-core/multi-thread niuansų ir lygiagretaus
> vyksmo netolygumų).

DBMS garantuoja labai paprastus dalykus - izoliaciją tarp BEGIN ir 
COMMIT, visa kita (kaip to išsidėstymas laike, rūšiavimo tvarka, etc) 
jau yra šalutiniai implementacijų efektai.

DBMS garantuoja, kad BEGIN įvyko kažkur tarp to momento, kai klientas 
išsiuntė užklausą ir kai gavo atsakymą.

DBMS garantuoja, kad COMMIT įvyko kažkur tarp to momento, kai klientas 
išsiuntė užklausą ir kai gavo atsakymą.

DBMS negarantuoja, kad dviem klientam išsiuntus BEGIN'us, jie kažkokia 
ypatinga tvarka bus įvykdyti, kaip ir negarantuoja, kad anksčiau 
išsiųsta užklausa būtinai gaus lockus anksčiau.

Kai klientas kažko prašo, nėra jokių garantijų, tiktai atsakymas gali 
pasakyt kas iš tiesų įvyko. Klientas nežino ar yra kitų transakcijų, ir 
jeigu žinotų, negalėtų nieko padaryt (mes čia galvojam, ar apsimoka 
išmokyt varikliuką klausyt tokių komandų kaipo "join/copy snapshot of 
transaction X").

Tai va kai ant tokio rinkinio garantijų ar jų nebuvimo reik statyt 
eiliavimo platformas, tai nebėra taip trivialu, tad galima užtikrinti 
tik labai ribotą efektą ir su daug didesnėm kainom.

O kol kas su geru hardwaru galima daryt keletą tūkstančių eilės 
operacijų per sekundę ir plot katučių, kai su specializuota programine 
įranga galima išlupt ir šimtą tūkstančių operacijų su tom pačiom 
garantijom.

Domas