InnoDB yhdistää kaksi mekanismia. MVCC antaa tavallisten SELECT:ien lukea johdonmukaisen tilannekuvan lukitsematta, joten lukijat eivät koskaan estä kirjoittajia. Lukot suojaavat kirjoituksia: // ottavat rivilukkoja, ja InnoDB käyttää myös (rivi + sitä edeltävä aukko) estääkseen phantomit REPEATABLE READ:n alla.
UPDATEDELETESELECT ... FOR UPDATELukkiuma on sykli: T1 pitää lukkoa A ja haluaa B:tä, kun taas T2 pitää B:tä ja haluaa A:ta. Kumpikaan ei pääse etenemään. InnoDB havaitsee syklin ja peruu yhden transaktion (halvemman uhrin) virheellä 1213, joten toinen valmistuu.
-- T1 -- T2
BEGIN; BEGIN;
UPDATE acct SET bal=bal-1 UPDATE acct SET bal=bal-1
WHERE id=1; -- lukitsee rivin 1 WHERE id=2; -- lukitsee rivin 2
UPDATE acct SET bal=bal+1 UPDATE acct SET bal=bal+1
WHERE id=2; -- odottaa T2:ta WHERE id=1; -- odottaa T1:tä => LUKKIUMA
-- ERROR 1213: Deadlock found; transaction rolled back
WHERE:si niin, että InnoDB lukitsee tietyt rivit, ei alueita tai (ilman indeksiä) käytännössä jokaista skannattua riviä.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK selittää kuka odotti mitäkin
Oikean samanaikaisuuden alla lukkokilpailu ja lukkiumat ovat ero skaalautuvan ja pysähtelevän tietokannan välillä. Sen tietäminen, että lukijat käyttävät MVCC:tä (joten ne eivät estä), että lukkiumat ovat odotettavissa ja uudelleenyritettäviä ja että johdonmukainen lukkojärjestys estää useimmat niistä, on juuri sitä mitä seniorin päivystystyö vaatii.
Kirjasto IT-haastattelukysymyksiä yksityiskohtaisine vastauksineen — Juniorista Senioriin.
Lahjoita