:) 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. 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...

As cia aisku spekuliuoju, nes nedirbu su MySQL, bet netiesiogiai mano 
teigini patvirtina tas faktas, kad suletejimas jauciamas didejant vartotoju 
skaiciui, o ne irasu skaiciui. Tiesiog laukianciu eile ilgeja greiciau, negu 
apdorojami irasai. Cia kaip pro vienas duris noretu praeiti 20 ir 50 zmoniu, 
vienaip ar kitaip tol, kol durys yra vienos, 50 zmoniu tai uzims daugiau 
laiko, o sakinukas geras, uztikrina tai, kad DBVS negaletu atidaryti 
papildomu duru ir naudotu tik vienas :)
Vargu ar galima sugalvoti geresni (toki paprasta ir elegantiska) sprendima 
norint uztikrinti, kad visos transakcijos butu vykdomos tik po viena, ir 
niekaip kitaip :)

Manau, kad si sprendima reikia keisti is pagrindu, transakcijos vargu ar 
pagerins greitaveika. Statau uz tai, kad bus dar blogiau nei dabar.


"NicMC"  wrote in message news:jbnq7t$tvp$1@trimpas.omnitel.net...

On 2011.12.07 13:56, Laimis wrote:
> InnoDB. Isolation level Serializable. Ir papasakosi čia, kaip pasikeitė
> sparta.

Pagooglinau, pabandžiau, veikimo mechanizmas visiškai analogiškas, ar
bus nauda? Gal aš per daug noriu, bet pabandysiu paaiškinti dar kartą.

Kiekvienas klientas pasiima tik 1 įrašą šitaip:

LOCK WRITE
SELECT * FROM `table` ORDER BY ID ASC LIMIT 1
DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
UNLOCK

Esmė - nei vienas klientas neturi teisės gauti įrašo, kurį jau gavo
kitas. Taigi SELECT neturi grąžinti to įrašo. Row-level lockingas rakina
įrašus UPDEITUI, bet ne SELECTUI. Viskas puikiai sukosi ir su 300000
įrašų, kai buvo tik 20 klientų. Šiuo metu klientų jau beveik 50. Ir jau
prie 150000 įrašų prasideda bėdos.

OK, su InnoDB galima perrašyti taip:
BEGIN
SELECT * FROM `table` ORDER BY ID ASC LIMIT 1 FOR UPDATE
DELETE FROM `table` WHERE `ID` = (iš SELECT'o)
COMMIT

O koks tolkas? Vis tiek likę klientai lauks...

Spėju, kad vis tik lieka keliai - hardware upgreidint / padaryti kažkokį
queue managerį, kuris iš DB selectintų daug, o jau paskui padalintų po
vieną.