InnoDB kombiniert zwei Mechanismen. MVCC lässt einfache SELECTs einen konsistenten Snapshot lesen, ohne zu sperren, sodass Leser nie Schreiber blockieren. Locks schützen Schreibvorgänge: // nehmen Zeilensperren, und InnoDB nutzt zusätzlich (Zeile + die Lücke davor), um Phantoms unter REPEATABLE READ zu verhindern.
UPDATEDELETESELECT ... FOR UPDATEEin Deadlock ist ein Zyklus: T1 hält Lock A und will B, während T2 B hält und A will. Keine kann fortfahren. InnoDB erkennt den Zyklus und rollt eine Transaktion zurück (das günstigere Opfer) mit Fehler 1213, sodass die andere abschließt.
-- 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, damit InnoDB bestimmte Zeilen sperrt, nicht Bereiche oder (ohne Index) faktisch jede gescannte Zeile.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK explains who waited on what
Unter realer Nebenläufigkeit sind Sperrkonflikte und Deadlocks der Unterschied zwischen einer Datenbank, die skaliert, und einer, die ins Stocken gerät. Zu wissen, dass Leser MVCC nutzen (also nicht blockieren), dass Deadlocks erwartbar und wiederholbar sind und dass eine konsistente Sperrreihenfolge die meisten davon verhindert, ist genau das, was seniorige On-Call-Arbeit verlangt.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden