0Pricing
SQL Academy · Lekcja

MVCC i przyczyny bloatu

Rozumieć wielowersyjny model współbieżności, przyczyny gromadzenia się martwych krotek oraz wpływ długich transakcji na bloat

MVCC i przyczyny bloatu to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej SQL Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs SQL Academy zawiera 4 lekcji w sumie.

Czym jest MVCC?

Multi-Version Concurrency Control, czyli kontrola współbieżności za pomocą wielu wersji. Zamiast blokowania PostgreSQL przechowuje wiele wersji wiersza. Odczytujący widzą spójny obraz danych, a zapisujący tworzą nowe wersje bez blokowania odczytów.

Jak działa UPDATE

UPDATE nie zmienia wiersza w miejscu:

  1. Oznacza starą wersję wiersza jako „martwą” w transakcji T
  2. Zapisuje nową wersję
  3. Inne transakcje widzą tę wersję, na którą pozwala ich migawka

Dlaczego powstaje bloat

Martwe wersje gromadzą się. Tabela rośnie, nawet jeśli liczba jej wierszy pozostaje stała. Bez czyszczenia zapytania skanują coraz więcej martwych wierszy.

Kiedy VACUUM odzyskuje miejsce

VACUUM oznacza martwe wiersze jako możliwe do ponownego użycia (w obrębie pliku tabeli). Nie zmniejsza plików, chyba że są one całkowicie puste na końcu. VACUUM FULL przepisuje tabelę — wymaga wyłącznej blokady i działa wolno.

Autovacuum

PostgreSQL uruchamia autovacuum w tle. Proces jest uruchamiany, gdy liczba martwych wierszy przekroczy próg:

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

Obciążenia powodujące bloat

  • Dużo operacji UPDATE na małych lub intensywnie używanych tabelach
  • Duże partie DELETE (VACUUM musi zwolnić miejsce)
  • Długotrwałe transakcje blokujące VACUUM (utrzymują migawki)
  • Sesje bezczynne w transakcji, które gromadzą martwe wiersze w intensywnie używanych tabelach

Diagnozowanie bloat

Rozszerzenie pgstattuple podaje dokładne wartości:

CREATE EXTENSION pgstattuple;

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

SELECT * FROM pgstatindex('orders_user_id_idx');

Długie transakcje blokują VACUUM

VACUUM może czyścić tylko wiersze starsze od najstarszej aktywnej transakcji. Czterogodzinna sesja bezczynna w transakcji oznacza 4 godziny nieusuniętych martwych wierszy.

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;

Ochrona przed przepełnieniem identyfikatorów

Identyfikatory transakcji mają 32 bity. Jeśli autovacuum nie nadąża, klaster jest zagrożony „przepełnieniem” i przechodzi w tryb ochronny (wymuszone VACUUM). Należy monitorować:

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

Usunięcie logiczne ≠ fizyczne

DELETE oznacza wiersze jako martwe; miejsce można odzyskać dopiero za pomocą VACUUM. Masowe operacje DELETE, po których nie uruchomiono VACUUM, pozostawiają ogromne skupiska martwych wierszy.

Aktualizacje HOT

Jeśli aktualizują Państwo wyłącznie kolumny bez indeksów i na tej samej stronie istnieje wolne miejsce, PostgreSQL wykonuje aktualizację HOT (Heap-Only Tuple) — nie modyfikuje indeksu i powoduje mniej bloatu.

Ograniczanie bloat

  • Skracać transakcje
  • Unikać szerokich operacji UPDATE na indeksowanych kolumnach (HOT nie może zadziałać)
  • Agresywnie dostrajać autovacuum dla intensywnie używanych tabel
  • Używać pg_repack do przebudowy bez długotrwałych blokad

Podsumowanie

MVCC umożliwia współbieżność kosztem gromadzenia martwych wierszy.

  • VACUUM usuwa martwe wiersze
  • Autovacuum jest niezbędny — nie należy go wyłączać
  • Długotrwałe transakcje blokują czyszczenie
  • Diagnozowanie za pomocą pgstattuple

Szybkie sprawdzenie

Dlaczego operacja UPDATE nie zmniejsza tabeli, nawet gdy zmienia się tylko jedna kolumna?

Często zadawane pytania

Czy lekcja „MVCC i przyczyny bloatu” jest bezpłatna?

Tak — pełny tekst „MVCC i przyczyny bloatu” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu SQL Academy, przejdź na CoddyKit PRO. Kurs SQL Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „MVCC i przyczyny bloatu”?

Rozumieć wielowersyjny model współbieżności, przyczyny gromadzenia się martwych krotek oraz wpływ długich transakcji na bloat Ćwiczysz SQL Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć SQL Academy?

Nie wymagamy żadnego doświadczenia. SQL Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „MVCC i przyczyny bloatu”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji SQL Academy?

Tak. Każda lekcja SQL Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. MVCC i przyczyny bloatu
  2. VACUUM, autovacuum, vacuum_cost_delay
  3. ANALYZE i pg_statistic
  4. Skanowanie wyłącznie indeksu i Visibility Map
← Powrót do SQL Academy