MVCC (Multiversion Concurrency Control, Mehrversionen-Gleichläufigkeitskontrolle) ist das Verfahren, mit dem moderne Datenbanksysteme Reads und Writes entkoppeln: Statt eine Zeile zu sperren, wird bei jeder Änderung eine neue Version angelegt. Jede Transaktion arbeitet auf einem konsistenten Snapshot — sie sieht den Datenbestand so, wie er zu ihrem Start (oder zu ihrer Anweisung) war.
Die Kernidee: Versionen statt Sperren
Bei MVCC gibt es zu einer logischen Zeile mehrere physische Versionen. Eine Transaktion, die schreibt, ändert die bestehende Zeile nicht in-place, sondern erzeugt eine neue Version; die alten Versionen bleiben für laufende Leser erhalten. Dadurch gilt der berühmte Grundsatz: Leser blockieren keine Schreiber, Schreiber blockieren keine Leser. Lesende Transaktionen müssen nicht warten und können trotzdem nie unbestätigte Daten sehen.
Die Wurzeln des Verfahrens liegen in der Dissertation von David P. Reed (MIT, 1978) und der Übersichtsarbeit Concurrency Control in Distributed Database Systems von Philip A. Bernstein und Nathan Goodman (ACM Computing Surveys, 1981), die MVCC ausführlich beschreibt.
Snapshot Isolation: die MVCC-Isolationsebene
MVCC ist der technische Unterbau von Snapshot Isolation: Eine Transaktion liest aus ihrem Snapshot, schreibt neue Versionen und gewinnt beim Commit nach dem Prinzip First-Commiter-Wins — schreibt eine zweite Transaktion dieselbe Zeile, bricht die spätere ab. Auch Read Committed (in PostgreSQL mit Statement-Snapshot) und Repeatable Read (in InnoDB mit Transaktions-Snapshot) sind MVCC-Umsetzungen.
Die Grenze von MVCC ist bekannt: Es verhindert Dirty Reads und Non-Repeatable Reads, aber nicht die Anomalie des Write Skew — zwei Transaktionen können disjunkte Zeilen schreiben und gemeinsam eine Invariante verletzen. Serializable Snapshot Isolation (SSI) beobachtet gefährliche Abhängigkeiten und bricht solche Transaktionen ab.
Praxis: Wie die Systeme MVCC umsetzen
- PostgreSQL: MVCC über Zeilenversionen mit Transaktions-IDs; alte Versionen räumt der VACUUM-Prozess ab (Garbage Collection).
- MySQL InnoDB: Versionen über den Undo-Log mit Versionskette (Version Chain); Read Views bestimmen die Sichtbarkeit.
- Oracle: Snapshot-basiert (Read Committed = Snapshot Isolation); bei Konflikten ORA-08177 unter Serializable.
- SQL Server: Row-Versioning über READ_COMMITTED_SNAPSHOT und ALLOW_SNAPSHOT_ISOLATION.
MVCC ist der Gegenentwurf zu Two-Phase Locking: Dort wird serialisiert, indem Transaktionen Sperren halten; hier wird serialisiert, indem Konflikte beim Commit entschieden werden. In der Praxis kombinieren Systeme beide Ideen — InnoDB etwa nutzt MVCC für Reads und 2PL für Schreib- und Sperrzugriffe.
Verwandte Grundlagen: Transaktion, ACID, Lost Update, Deadlock.