InnoDB kombinerer to mekanismer. MVCC lar vanlige SELECT-er lese et konsistent snapshot uten låsing, slik at lesere aldri blokkerer skrivere. Locks beskytter skriving: UPDATE// tar row locks, og InnoDB bruker også (rad + gapet foran den) for å stoppe phantoms under REPEATABLE READ.
DELETESELECT ... FOR UPDATEEn deadlock er en syklus: T1 holder lås A og vil ha B, mens T2 holder B og vil ha A. Ingen av dem kan gå videre. InnoDB oppdager syklusen og ruller tilbake én transaksjon (det billigste offeret) med feil 1213, slik at den andre fullfører.
-- T1 -- T2
BEGIN; BEGIN;
UPDATE acct SET bal=bal-1 UPDATE acct SET bal=bal-1
WHERE id=1; -- locks row 1 WHERE id=2; -- locks row 2
UPDATE acct SET bal=bal+1 UPDATE acct SET bal=bal+1
WHERE id=2; -- waits for T2 WHERE id=1; -- waits for T1 => DEADLOCK
-- ERROR 1213: Deadlock found; transaction rolled back
WHERE-en din slik at InnoDB låser spesifikke rader, ikke ranges eller (uten en indeks) i praksis hver rad som skannes.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK explains who waited on what
Under reell samtidighet er lock contention og deadlocks forskjellen mellom en database som skalerer og en som stopper opp. Å vite at lesere bruker MVCC (så de ikke blokkerer), at deadlocks er forventet og kan prøves på nytt, og at konsistent låserekkefølge forhindrer de fleste av dem, er nøyaktig det senior on-call-arbeid krever.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner