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

Palyginkim:

BEGIN;
SELECT ... FOR UPDATE;
UPDATE ...;
COMMIT;

su:

UPDATE ...;
SELECT ...;

pirmuoju atveju UPDATE'as dar nežino ką darys, tad reikės arba kliento 
apsisprendimo, arba visokių tarpinių parametrų ar storedprocedūrų 
nenorint laukt tinklo.

Pirmu atveju lockinama/atlockinama per tris užklausas, antru per vieną.

Pirmu atveju įeinama/išeinama iš InnoDB kelis kartus, antru atveju vieną 
(hehe, innodb_thread_concurrency šitoj vietoj gali gerai užmušt - 
lokinanti tranzakcija gali būt priversta palaukt truputį, kol kitos 
patikrins, gali jos veikt ar ne :-)

Pirmu atveju tranzakcijos/locko ilgį įtakoja daug išorinių veiksmų, 
antru atveju tik InnoDB tranzakcijų performancas.

Na čia, jeigu tikrai greičio reikia ;-)
Jeigu InnoDB leistų, kaip kažkas minėjo MS SQL atvejų, praleist 
užrakintus įrašus, tai jo, būtų galima dar geriau tai sukonstruot. Beje, 
tam mes turim vidinį task'ą (o jie dažniausiai pasibaigia InnoDB 
pataisymais ;-)

Bėda tik ta, kad tokio tipo sistemos neturėtų gyvent RDBMS'uose 
dažniausiai, ir specialiai pabūrus sistemų programuotojui galima padaryt 
bent 10x efektyvesnes sistemas su norimu rezultatu.

Kita bėda, kad tokių sistemų dažnai nėra labai daug, tad tingisi tam 
ieškot sistemų programuotojo ir galima tiesiog skaldyt eiles ir spręst 
brute force pavidalu, metant daugiau geležies.

Domas