SQL Academy · Lektion

MVCC und Ursachen für Bloat

Verstehen Sie die Multiversionsnebenläufigkeitskontrolle, warum veraltete Tupel angehäuft werden und wie lange Transaktionen Bloat verursachen.

MVCC und Ursachen für Bloat ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 1 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 SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist MVCC?

Multi-Version Concurrency Control. Statt zu sperren, verwaltet PostgreSQL mehrere Versionen einer Zeile. Leser sehen einen konsistenten Snapshot; Schreiber erstellen neue Versionen, ohne Leser zu blockieren.

So funktioniert ein UPDATE

Ein UPDATE ändert die Zeile nicht direkt:

Die alte Zeilenversion wird bei Transaktion T als „tot“ markiert
Eine neue Version wird geschrieben
Andere Transaktionen sehen die Version, die ihr Snapshot zulässt

Warum Bloat entsteht

Tote Versionen sammeln sich an. Die Tabelle wächst, auch wenn ihre Zeilenanzahl konstant bleibt. Ohne Bereinigung durchsuchen Abfragen zunehmend mehr tote Zeilen.

Wann VACUUM Speicherplatz zurückgewinnt

VACUUM markiert tote Zeilen als wiederverwendbar (innerhalb der Tabellendatei). Die Dateien werden NICHT verkleinert, es sei denn, sie sind am Ende vollständig leer. VACUUM FULL schreibt die Tabelle neu — exklusive Sperre, langsam.

Autovacuum

PostgreSQL führt Autovacuum im Hintergrund aus. Es wird ausgelöst, wenn die Anzahl toter Zeilen einen Schwellenwert überschreitet:

autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
-- vacuum when dead_rows > 50 + 0.2 * total_rows

Arbeitslasten, die Bloat verursachen

Viele UPDATEs auf kleinen oder stark ausgelasteten Tabellen
Große DELETE-Batches (VACUUM muss Speicherplatz freigeben)
Lang laufende Transaktionen blockieren VACUUM (sie halten Snapshots)
Idle-in-Transaction-Sitzungen sammeln auf stark ausgelasteten Tabellen tote Zeilen an

Bloat diagnostizieren

Die Erweiterung pgstattuple liefert exakte Werte:

CREATE EXTENSION pgstattuple;

SELECT * FROM pgstattuple('orders');
-- table_len, tuple_count, dead_tuple_count, free_space, etc.

SELECT * FROM pgstatindex('orders_user_id_idx');

Lange Transaktionen blockieren VACUUM

VACUUM kann nur Zeilen bereinigen, die älter als die älteste aktive Transaktion sind. Eine vier Stunden dauernde Idle-in-Transaction-Sitzung bedeutet vier Stunden lang nicht freigegebene tote Zeilen.

SELECT pid, state, xact_start, NOW() - xact_start AS duration
FROM pg_stat_activity
WHERE state IN ('active', 'idle in transaction')
ORDER BY duration DESC NULLS LAST;

Schutz vor Transaktions-ID-Überlauf

Transaktions-IDs sind 32 Bit groß. Wenn Autovacuum nicht Schritt halten kann, droht dem Cluster ein „Wraparound“, und es wechselt in den Sicherheitsmodus (erzwungenes VACUUM). Überwachen Sie:

SELECT datname, age(datfrozenxid) FROM pg_database
ORDER BY age(datfrozenxid) DESC;

Logisches Löschen ≠ physisches Löschen

DELETE markiert Zeilen als tot; der Speicherplatz kann erst durch VACUUM zurückgewonnen werden. Massenlöschungen ohne anschließendes VACUUM hinterlassen große Mengen toter Zeilen.

HOT-Updates

Wenn Sie nur nicht indizierte Spalten aktualisieren und auf derselben Seite ein freier Platz vorhanden ist, führt PostgreSQL ein HOT-Update (Heap-Only Tuple) durch — keine Änderung am Index und weniger Bloat.

Bloat reduzieren

Halten Sie Transaktionen kurz
Vermeiden Sie umfangreiche UPDATEs auf indizierten Spalten (HOT kann dann nicht greifen)
Stimmen Sie Autovacuum für stark ausgelastete Tabellen aggressiv ab
Verwenden Sie pg_repack, um Tabellen ohne lange Sperren neu zu schreiben

Zusammenfassung

MVCC ermöglicht Nebenläufigkeit, führt aber zum Ansammeln toter Zeilen.

VACUUM bereinigt tote Zeilen
Autovacuum ist unverzichtbar — deaktivieren Sie es nicht
Lange Transaktionen blockieren die Bereinigung
Diagnostizieren Sie das Problem mit pgstattuple

Kurzer Check

Warum wird die Tabelle durch ein UPDATE nicht kleiner, selbst wenn sich nur eine Spalte ändert?

Häufig gestellte Fragen

Ist die Lektion „MVCC und Ursachen für Bloat“ kostenlos?

Ja — der vollständige Text von „MVCC und Ursachen für Bloat“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „MVCC und Ursachen für Bloat“?

Verstehen Sie die Multiversionsnebenläufigkeitskontrolle, warum veraltete Tupel angehäuft werden und wie lange Transaktionen Bloat verursachen. Du übst SQL Academy 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 SQL Academy zu starten?

Keine Vorkenntnisse erforderlich. SQL Academy 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 1 von 4.

Wie lange dauert die Lektion „MVCC und Ursachen für Bloat“?

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 SQL Academy-Lektion Code schreiben und ausführen?

Ja. Jede SQL Academy-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

← Zurück zu SQL Academy