InnoDB kombinerer to mekanismer. MVCC lader almindelige SELECTs læse et konsistent snapshot uden at låse, så readers aldrig blokerer writers. Locks beskytter writes: UPDATE// tager row locks, og InnoDB bruger også (rækken + gabet før den) for at stoppe phantoms under REPEATABLE READ.
DELETESELECT ... FOR UPDATEEn deadlock er en cyklus: T1 holder lock A og vil have B, mens T2 holder B og vil have A. Ingen af dem kan fortsætte. InnoDB opdager cyklussen og ruller én transaktion tilbage (det billigere offer) med fejl 1213, så den anden fuldføres.
-- 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, så InnoDB låser specifikke rækker, ikke ranges eller (uden et indeks) reelt hver scannet række.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK explains who waited on what
Under reel samtidighed er lock-contention og deadlocks forskellen mellem en database, der skalerer, og en, der går i stå. At vide, at readers bruger MVCC (så de ikke blokerer), at deadlocks er forventede og retry-bare, og at konsistent lock-rækkefølge forhindrer de fleste af dem, er præcis, hvad senior on-call-arbejde kræver.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér