Wersje WordPressa: miejsce w bazie, limity i rzetelny pomiar

Wersje wpisów w WordPressie zachowują stany treści do porównania i przywrócenia. Taka historia zwiększa również ilość danych w bazie. Duża liczba wersji nie dowodzi jednak ani usterki, ani powolnego działania witryny.

Pomiar tej witryny przeprowadzony wyłącznie przez odczyt 24 października 2026 o 04:19 UTC wykazał 7635 wersji wśród 12 284 wierszy tabeli wpisów. Wersje zawierały około 79,4 procent bajtów zapisanej treści. Ten datowany wynik zastępuje wcześniejsze, już nieaktualne liczby.

Co WordPress faktycznie zapisuje

Wersja domyślnie zawiera tytuł, treść i zajawkę. WordPress zapisuje bieżący stan redakcyjny w osobnym wierszu powiązanym z wpisem. Po kolejnych zmianach taki zapis staje się wcześniejszym stanem. Odpowiednio zarejestrowane metadane również mogą uczestniczyć w wersjonowaniu. Wersja nie jest jednak pełną kopią wszystkich właściwości wpisu ani całej witryny.

Nie każdy zapis tworzy nową wersję. Typ treści musi obsługiwać wersjonowanie, funkcja musi być włączona, a odpowiednie pola zwykle muszą ulec zmianie. Filtry mogą modyfikować to zachowanie. Skrypt zmieniający 300 wpisów nie musi więc utworzyć 300 wersji. Bezpośrednie aktualizacje SQL całkowicie omijają zwykły przebieg operacji WordPressa.

Automatyczne zapisy działają inaczej: WordPress utrzymuje autosave dla każdej pary wpis–użytkownik. Istniejący autosave jest aktualizowany; zapis zgodny z aktualnym wpisem może zostać usunięty.

Zliczenie zamiast wartości szacunkowej

Badana tabela używa silnika InnoDB. Dla tego silnika information_schema.TABLES.TABLE_ROWS może zawierać oszacowanie. Podczas pomiaru przegląd pokazał 10 649 wierszy, a bezpośrednie zliczenie wykazało 12 284. Taka różnica nie dowodzi utraty rekordów.

Zliczono 7635 wersji, 2958 załączników, 1689 wpisów i stron oraz dwa pozostałe rekordy stylów globalnych i nawigacji. Liczba 1689 obejmuje wszystkie statusy, w tym szkice, zaplanowane wpisy i kosz. Opublikowanych było 1290 wpisów i stron. Rekord załącznika nie odpowiada też każdemu automatycznie utworzonemu plikowi obrazu.

Rozmiar treści to nie rozmiar pliku

Za pomocą OCTET_LENGTH(post_content) zmierzono 92 563 135 bajtów w wersjach oraz 23 963 672 bajty we wpisach i stronach: odpowiednio około 88,3 i 22,9 MiB. Jeden MiB to 1 048 576 bajtów. Dwa pozostałe rekordy zawierały łącznie jeszcze 74 bajty; załączniki miały w tym pomiarze puste pola treści. W innych przypadkach załączniki mogą zawierać opisy.

Zapytanie mierzy wyłącznie kolumnę post_content. Pomija tytuły, inne kolumny, metadane, indeksy i już przydzielone miejsce tabeli. Z 88,3 MiB treści wersji nie wynika zatem możliwość odzyskania dokładnie 88,3 MiB miejsca na dysku ani równie duże zmniejszenie skompresowanych kopii zapasowych.

Gdzie pojawia się koszt

Typowe publiczne zapytania o wpisy wykluczają wersje. Nie gwarantuje to identycznego czasu ładowania z wersjami i bez wersji: zapytania, indeksy, pamięci podręczne, rozszerzenia i ekrany administracyjne mogą zachowywać się różnie. Ta kontrola nie obejmowała porównawczego testu szybkości ładowania.

Dodatkowe rekordy zwiększają zawartość logicznych eksportów bazy. Czas wykonywania kopii i przesyłania danych zależy jednak także od kompresji, nośników oraz sposobu eksportu. Trzykrotnie większa treść nie oznacza automatycznie trzykrotnie dłuższego kopiowania.

Dobór limitu wersji

WP_POST_REVISIONS steruje przechowywaniem zwykłych wersji. true lub -1 oznacza brak limitu, dodatnia liczba całkowita ogranicza liczbę wersji na wpis, a false lub 0 wyłącza zwykłe wersje. Automatyczne zapisy pozostają wyjątkiem. Badana instalacja używała true. Filtry WordPressa mogą zmienić efektywny limit.

Właściwy limit zależy od częstotliwości edycji i potrzebnej głębokości historii do odtworzenia. Trzy do pięciu wersji nie jest uniwersalnym zaleceniem. Przed dużymi zmianami sprawdzona kopia zapasowa i czytelny dziennik zmian uzupełniają historię wersji.

SELECT post_type, post_status,
       COUNT(*) AS row_count,
       COALESCE(SUM(OCTET_LENGTH(post_content)), 0) AS content_bytes
FROM wp_posts
GROUP BY post_type, post_status
ORDER BY post_type, post_status;