Deadlocks, Sperren und MVCC
Wie Datenbanken Konflikte vermeiden und welche Kompromisse zwischen Sperren und Snapshots bestehen.
Deadlocks, Sperren und MVCC ist eine kostenlose Coding Interview Prep-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Coding Interview Prep-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.
Wie Datenbanken Isolation tatsächlich durchsetzen
Isolationsstufen sind das Versprechen; Sperren und MVCC sind die Mechanismen, die es einlösen. Interviewer fragen danach, um zu sehen, ob Sie verstehen, was im Hintergrund passiert, wenn Transaktionen aufeinanderprallen.
Es gibt zwei grundlegende Strategien:
- Pessimistisch (Sperren): konkurrierende Zugriffe blockieren, bis eine Sperre freigegeben wird.
- Optimistisch / MVCC: allen das Lesen eines konsistenten Snapshots erlauben und Konflikte beim Commit erkennen.
Diese Lektion behandelt Sperren, Deadlocks und MVCC sowie die jeweiligen Abwägungen.
Gemeinsame und exklusive Sperren
Klassische Sperrverfahren verwenden zwei Hauptmodi:
- Gemeinsame Sperre (S) für Lesevorgänge. Mehrere Transaktionen können gleichzeitig eine gemeinsame Sperre für dieselbe Zeile halten.
- Exklusive Sperre (X) für Schreibvorgänge. Nur eine Transaktion kann sie halten, und sie blockiert alle anderen Sperren für diese Zeile.
Die Regel lautet: S ist mit S kompatibel, X dagegen mit keiner anderen Sperre. Ein Schreibvorgang muss auf alle Leser warten, und Leser müssen auf einen Schreibvorgang warten.
Explizite Sperren mit SELECT FOR UPDATE
Sie können für Zeilen, die Sie nur lesen, eine Schreibsperre anfordern, um zu verhindern, dass andere sie ändern, bevor Sie handeln. Dies ist der Standardweg, um Lost Updates in einem Lese-Änderungs-Schreibzyklus zu vermeiden.
SELECT ... FOR UPDATE setzt exklusive Zeilensperren; die Zeilen bleiben gesperrt, bis Sie COMMIT oder ROLLBACK ausführen.
BEGIN;
-- lock the row so no one else can modify it concurrently
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT; -- lock released hereWas ist ein Deadlock?
Ein Deadlock tritt auf, wenn zwei oder mehr Transaktionen jeweils eine Sperre halten, die die andere benötigt, und dadurch ein Zyklus entsteht, in dem keine fortfahren kann.
Der klassische Fall: T1 sperrt Zeile A und fordert dann Zeile B an; T2 sperrt Zeile B und fordert dann Zeile A an. Beide warten endlos aufeinander.
Datenbanken erkennen dies mithilfe eines Wait-for-Graphen. Wird ein Zyklus gefunden, wählt die Engine eine Opfertransaktion aus und bricht sie ab. Sie gibt einen Deadlock-Fehler zurück, sodass die übrigen Transaktionen fortfahren können.
Deadlock: Zeitablauf
Beobachten Sie, wie sich die Sperrreihenfolge kreuzt. T1 sperrt Zeile 1 und fordert dann Zeile 2 an; T2 sperrt Zeile 2 und fordert dann Zeile 1 an. Da keine der beiden Transaktionen ihre Sperre freigibt, bricht die Engine eine von ihnen ab.
Die abgebrochene Transaktion erhält einen Fehler wie deadlock detected und muss es erneut versuchen. Die verbleibende Transaktion führt ihren Commit normal aus.
-- T1 | -- T2
BEGIN; | BEGIN;
UPDATE accounts SET balance=balance-10 | UPDATE accounts SET balance=balance-10
WHERE id=1; -- locks row 1 | WHERE id=2; -- locks row 2
UPDATE accounts SET balance=balance+10 | UPDATE accounts SET balance=balance+10
WHERE id=2; -- waits for T2 | WHERE id=1; -- waits for T1 -> CYCLE
-- one transaction is chosen as victim and rolled backDeadlocks verhindern
Sie können Deadlocks nicht vollständig beseitigen, aber ihr Auftreten selten machen. Standardantworten im Vorstellungsgespräch:
- Konsistente Reihenfolge beim Sperren: Sperren Sie Zeilen immer in derselben Reihenfolge (zum Beispiel in aufsteigender Reihenfolge der id). Dadurch wird der Zyklus verhindert.
- Transaktionen kurz halten: Halten Sie Sperren so kurz wie möglich.
- Isolationsstufe senken, wenn dies sicher ist: weniger Sperren, weniger Konflikte.
- Wiederholungslogik hinzufügen: Opfertransaktionen sollten automatisch erneut ausgeführt werden.
Eine konsistente Reihenfolge ist die wirksamste einzelne Maßnahme und die erste, die Interviewer hören möchten.
Sperrgranularität
Sperren können auf unterschiedlichen Ebenen gesetzt werden – eine Abwägung zwischen Nebenläufigkeit und Overhead:
- Sperren auf Zeilenebene ermöglichen eine hohe Nebenläufigkeit, verursachen aber einen höheren Verwaltungsaufwand.
- Sperren auf Seiten- oder Tabellenebene sind kostengünstiger zu verwalten, blockieren aber mehr Transaktionen.
Einige Engines eskalieren von Zeilen- zu Tabellensperren, wenn eine Transaktion zu viele Zeilen betrifft (Sperreneskalation). Das erklärt, warum ein großes Bulk-UPDATE plötzlich alle anderen blockieren kann.
MVCC: Der Snapshot-Ansatz
MVCC (Multi-Version Concurrency Control) ist die Methode, mit der Postgres, Oracle und InnoDB die meisten Lesesperren vermeiden. Statt zu sperren, hält die Datenbank mehrere Versionen jeder Zeile vor.
Der wichtigste Vorteil und ein beliebter Interview-Satz lautet: Lesevorgänge blockieren keine Schreibvorgänge, und Schreibvorgänge blockieren keine Lesevorgänge.
Jede Transaktion sieht einen konsistenten Snapshot zu einem bestimmten Zeitpunkt, während Schreibvorgänge neue Zeilenversionen erzeugen, statt Werte direkt zu überschreiben.
Wie MVCC im Hintergrund funktioniert
Beim Aktualisieren einer Zeile schreibt MVCC eine neue Version und behält die alte bei. Jede Version enthält Metadaten zur Transaktions-ID (in Postgres xmin und xmax), die markieren, wann sie sichtbar wurde und wann sie ersetzt wurde.
Der Snapshot einer Transaktion bestimmt, welche Version sie sieht. Alte Versionen, die keine Transaktion mehr sehen kann, werden zu Dead Tuples und später von einem Bereinigungsprozess zurückgefordert. In Postgres übernimmt diesen Prozess VACUUM; wird es nicht ausgeführt, kommt es zu Table Bloat, einer häufigen Anschlussfrage.
Sperren vs. MVCC: Die Abwägung
Fassen Sie den Vergleich prägnant zusammen:
- Reine Sperrverfahren: einfache Gewährleistung der Korrektheit, aber Lese- und Schreibvorgänge blockieren sich gegenseitig, was die Nebenläufigkeit beeinträchtigt.
- MVCC: hervorragende Nebenläufigkeit bei Lesevorgängen und keine Lesesperren, dafür aber Speicherplatz für Versionen und Bereinigungsaufwand (VACUUM, Bloat); außerdem werden weiterhin Sperren für Konflikte zwischen Schreibvorgängen benötigt.
Auch MVCC-Engines setzen bei Schreibvorgängen Sperren ein: Zwei Transaktionen, die dieselbe Zeile aktualisieren, müssen nacheinander ausgeführt werden. MVCC beseitigt Konflikte zwischen Lese- und Schreibvorgängen, nicht zwischen Schreibvorgängen.
Optimistisches Locking und Versionsspalten
Zusätzlich zu MVCC auf Engine-Ebene ergänzen Anwendungen häufig optimistisches Locking für Lese-Änderungs-Schreibvorgänge über lange Benutzersitzungen. Sie fügen eine version-Spalte hinzu, lesen sie aus und verlangen bei der Aktualisierung, dass die Version übereinstimmt, wobei Sie sie erhöhen.
Wenn eine andere Transaktion die Zeile zuerst aktualisiert hat, stimmt die Version nicht mehr überein, null Zeilen sind betroffen und Ihr Code weiß, dass er die Daten neu laden und es erneut versuchen muss. Während der Benutzer überlegt, werden keine Sperren gehalten, sodass die Nebenläufigkeit hoch bleibt. Interviewer schätzen dieses Verfahren bei der Frage: „Wie gehen Sie damit um, wenn zwei Benutzer denselben Datensatz bearbeiten?“
-- read: SELECT id, data, version FROM items WHERE id = 1; -- version = 7
UPDATE items
SET data = 'new value', version = version + 1
WHERE id = 1 AND version = 7;
-- if rows affected = 0, someone else changed it: reload and retryKurze Überprüfung
Testen Sie den zentralen MVCC-Interview-Satz.
Zusammenfassung: Sperren, Deadlocks und MVCC
Sie können nun die Mechanismen hinter der Isolation erklären:
- Gemeinsame und exklusive Sperren koordinieren den Zugriff;
SELECT FOR UPDATEsetzt explizite Schreibsperren. - Deadlocks sind Sperrzyklen; die Engine bricht eine Opfertransaktion ab, und eine konsistente Reihenfolge beim Sperren verhindert die meisten Deadlocks.
- MVCC hält Zeilenversionen vor, sodass Lese- und Schreibvorgänge sich nicht blockieren – um den Preis von Bereinigungsaufwand (VACUUM, Bloat).
Wenn Sie diese Mechanismen mit den Isolationsstufen und Anomalien aus den früheren Lektionen verbinden, können Sie ein vollständiges Vorstellungsgespräch zum Thema Nebenläufigkeit von Anfang bis Ende bewältigen.
Häufig gestellte Fragen
Ist die Lektion „Deadlocks, Sperren und MVCC“ kostenlos?
Ja — der vollständige Text von „Deadlocks, Sperren und MVCC“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Coding Interview Prep-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Coding Interview Prep-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Deadlocks, Sperren und MVCC“?
Wie Datenbanken Konflikte vermeiden und welche Kompromisse zwischen Sperren und Snapshots bestehen. Du übst Coding Interview Prep mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Coding Interview Prep zu starten?
Keine Vorkenntnisse erforderlich. Coding Interview Prep auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Deadlocks, Sperren und MVCC“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Coding Interview Prep-Lektion Code schreiben und ausführen?
Ja. Jede Coding Interview Prep-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- ACID-Eigenschaften erklärt
- Die vier Isolationsstufen
- Dirty Reads, Non-Repeatable Reads und Phantom Reads
- Deadlocks, Sperren und MVCC