{"id":13636,"date":"2026-10-24T18:25:00","date_gmt":"2026-10-24T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13636"},"modified":"2026-10-24T06:36:05","modified_gmt":"2026-10-24T04:36:05","slug":"2483-wersje-na-926-wpisow-co-naprawde-zajmuje-miejsce-w-bazie-wordpressa","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/wordpress-plugins-tricks-pl\/tutorials-pl-wordpress-plugins-tricks-pl\/2483-wersje-na-926-wpisow-co-naprawde-zajmuje-miejsce-w-bazie-wordpressa\/","title":{"rendered":"Wersje WordPressa: miejsce w bazie, limity i rzetelny pomiar"},"content":{"rendered":"

Wersje wpis\u00f3w w WordPressie zachowuj\u0105 stany tre\u015bci do por\u00f3wnania i przywr\u00f3cenia. Taka historia zwi\u0119ksza r\u00f3wnie\u017c ilo\u015b\u0107 danych w bazie. Du\u017ca liczba wersji nie dowodzi jednak ani usterki, ani powolnego dzia\u0142ania witryny.<\/p>\n

Pomiar tej witryny przeprowadzony wy\u0142\u0105cznie przez odczyt 24 pa\u017adziernika 2026 o 04:19 UTC<\/strong> wykaza\u0142 7635 wersji w\u015br\u00f3d 12 284 wierszy tabeli wpis\u00f3w. Wersje zawiera\u0142y oko\u0142o 79,4 procent bajt\u00f3w zapisanej tre\u015bci. Ten datowany wynik zast\u0119puje wcze\u015bniejsze, ju\u017c nieaktualne liczby.<\/p>\n

\"Wiersze
Pomiar z 24 pa\u017adziernika 2026, 04:19 UTC: 7635 wersji; 79,4% bajt\u00f3w post_content. To nie pomiar miejsca na dysku ani szybko\u015bci.<\/figcaption><\/figure>\n

Co WordPress faktycznie zapisuje<\/h2>\n

Wersja domy\u015blnie zawiera tytu\u0142, tre\u015b\u0107 i zajawk\u0119. WordPress zapisuje bie\u017c\u0105cy stan redakcyjny w osobnym wierszu powi\u0105zanym z wpisem. Po kolejnych zmianach taki zapis staje si\u0119 wcze\u015bniejszym stanem. Odpowiednio zarejestrowane metadane r\u00f3wnie\u017c mog\u0105 uczestniczy\u0107 w wersjonowaniu. Wersja nie jest jednak pe\u0142n\u0105 kopi\u0105 wszystkich w\u0142a\u015bciwo\u015bci wpisu ani ca\u0142ej witryny.<\/p>\n

Nie ka\u017cdy zapis tworzy now\u0105 wersj\u0119. Typ tre\u015bci musi obs\u0142ugiwa\u0107 wersjonowanie, funkcja musi by\u0107 w\u0142\u0105czona, a odpowiednie pola zwykle musz\u0105 ulec zmianie. Filtry mog\u0105 modyfikowa\u0107 to zachowanie. Skrypt zmieniaj\u0105cy 300 wpis\u00f3w nie musi wi\u0119c utworzy\u0107 300 wersji. Bezpo\u015brednie aktualizacje SQL ca\u0142kowicie omijaj\u0105 zwyk\u0142y przebieg operacji WordPressa.<\/p>\n

Automatyczne zapisy dzia\u0142aj\u0105 inaczej: WordPress utrzymuje autosave dla ka\u017cdej pary wpis\u2013u\u017cytkownik. Istniej\u0105cy autosave jest aktualizowany; zapis zgodny z aktualnym wpisem mo\u017ce zosta\u0107 usuni\u0119ty.<\/p>\n

Zliczenie zamiast warto\u015bci szacunkowej<\/h2>\n

Badana tabela u\u017cywa silnika InnoDB. Dla tego silnika information_schema.TABLES.TABLE_ROWS<\/code> mo\u017ce zawiera\u0107 oszacowanie. Podczas pomiaru przegl\u0105d pokaza\u0142 10 649 wierszy, a bezpo\u015brednie zliczenie wykaza\u0142o 12 284. Taka r\u00f3\u017cnica nie dowodzi utraty rekord\u00f3w.<\/p>\n

Zliczono 7635 wersji, 2958 za\u0142\u0105cznik\u00f3w, 1689 wpis\u00f3w i stron oraz dwa pozosta\u0142e rekordy styl\u00f3w globalnych i nawigacji. Liczba 1689 obejmuje wszystkie statusy, w tym szkice, zaplanowane wpisy i kosz. Opublikowanych by\u0142o 1290 wpis\u00f3w i stron. Rekord za\u0142\u0105cznika nie odpowiada te\u017c ka\u017cdemu automatycznie utworzonemu plikowi obrazu.<\/p>\n

\n\"Symboliczne
\n<\/figure>\n

Rozmiar tre\u015bci to nie rozmiar pliku<\/h2>\n

Za pomoc\u0105 OCTET_LENGTH(post_content)<\/code> zmierzono 92 563 135 bajt\u00f3w w wersjach oraz 23 963 672 bajty we wpisach i stronach: odpowiednio oko\u0142o 88,3 i 22,9 MiB. Jeden MiB to 1 048 576 bajt\u00f3w. Dwa pozosta\u0142e rekordy zawiera\u0142y \u0142\u0105cznie jeszcze 74 bajty; za\u0142\u0105czniki mia\u0142y w tym pomiarze puste pola tre\u015bci. W innych przypadkach za\u0142\u0105czniki mog\u0105 zawiera\u0107 opisy.<\/p>\n

Zapytanie mierzy wy\u0142\u0105cznie kolumn\u0119 post_content<\/code>. Pomija tytu\u0142y, inne kolumny, metadane, indeksy i ju\u017c przydzielone miejsce tabeli. Z 88,3 MiB tre\u015bci wersji nie wynika zatem mo\u017cliwo\u015b\u0107 odzyskania dok\u0142adnie 88,3 MiB miejsca na dysku ani r\u00f3wnie du\u017ce zmniejszenie skompresowanych kopii zapasowych.<\/p>\n

Gdzie pojawia si\u0119 koszt<\/h2>\n

Typowe publiczne zapytania o wpisy wykluczaj\u0105 wersje. Nie gwarantuje to identycznego czasu \u0142adowania z wersjami i bez wersji: zapytania, indeksy, pami\u0119ci podr\u0119czne, rozszerzenia i ekrany administracyjne mog\u0105 zachowywa\u0107 si\u0119 r\u00f3\u017cnie. Ta kontrola nie obejmowa\u0142a por\u00f3wnawczego testu szybko\u015bci \u0142adowania.<\/p>\n

Dodatkowe rekordy zwi\u0119kszaj\u0105 zawarto\u015b\u0107 logicznych eksport\u00f3w bazy. Czas wykonywania kopii i przesy\u0142ania danych zale\u017cy jednak tak\u017ce od kompresji, no\u015bnik\u00f3w oraz sposobu eksportu. Trzykrotnie wi\u0119ksza tre\u015b\u0107 nie oznacza automatycznie trzykrotnie d\u0142u\u017cszego kopiowania.<\/p>\n

Dob\u00f3r limitu wersji<\/h2>\n

WP_POST_REVISIONS<\/code> steruje przechowywaniem zwyk\u0142ych wersji. true<\/code> lub -1<\/code> oznacza brak limitu, dodatnia liczba ca\u0142kowita ogranicza liczb\u0119 wersji na wpis, a false<\/code> lub 0<\/code> wy\u0142\u0105cza zwyk\u0142e wersje. Automatyczne zapisy pozostaj\u0105 wyj\u0105tkiem. Badana instalacja u\u017cywa\u0142a true<\/code>. Filtry WordPressa mog\u0105 zmieni\u0107 efektywny limit.<\/p>\n

W\u0142a\u015bciwy limit zale\u017cy od cz\u0119stotliwo\u015bci edycji i potrzebnej g\u0142\u0119boko\u015bci historii do odtworzenia. Trzy do pi\u0119ciu wersji nie jest uniwersalnym zaleceniem. Przed du\u017cymi zmianami sprawdzona kopia zapasowa i czytelny dziennik zmian uzupe\u0142niaj\u0105 histori\u0119 wersji.<\/p>\n

\n

Pytania i odpowiedzi<\/h2>\n

Czy nowy limit od razu usuwa wszystkie stare wersje?<\/h3>\n

Nie. Zwyk\u0142e ograniczanie historii odbywa si\u0119 osobno dla wpisu podczas tworzenia nowej wersji. Zmiana konfiguracji lub zapis bez zmian nie porz\u0105dkuje automatycznie ca\u0142ego zbioru. Wy\u0142\u0105czenie zwyk\u0142ych wersji r\u00f3wnie\u017c nie usuwa istniej\u0105cych wersji.<\/p>\n

Dlaczego unika\u0107 usuwania bezpo\u015brednio z tabeli wpis\u00f3w?<\/h3>\n

Pojedyncze SQL DELETE mo\u017ce pozostawi\u0107 powi\u0105zane metadane i wpisy pami\u0119ci podr\u0119cznej. Funkcja wp_delete_post_revision()<\/code> korzysta ze standardowej procedury usuwania WordPressa wraz z powi\u0105zanym porz\u0105dkowaniem. Usuwanie starych wersji wymaga sprawdzonej kopii zapasowej i jednoznacznie okre\u015blonego zakresu. Podczas tego pomiaru nie usuni\u0119to \u017cadnych wersji.<\/p>\n

Czy po usuni\u0119ciu maleje plik tabeli?<\/h3>\n

Niekoniecznie. InnoDB mo\u017ce ponownie wykorzysta\u0107 zwolnione miejsce wewn\u0105trz tabeli. Zwrot miejsca systemowi plik\u00f3w po przebudowie zale\u017cy mi\u0119dzy innymi od przestrzeni tabel i konfiguracji. Przebudowa mo\u017ce wymaga\u0107 dodatkowego miejsca i czasu serwisowego; nie uzasadnia to og\u00f3lnego zalecenia wykonania OPTIMIZE TABLE.<\/p>\n

Jakie zapytanie pokazuje podzia\u0142?<\/h3>\n

Poni\u017csze zapytanie wy\u0142\u0105cznie odczytuje dane i rozdziela typ tre\u015bci oraz status. Przedrostek wp_<\/code> musi odpowiada\u0107 rzeczywistemu przedrostkowi tabel.<\/p>\n

SELECT post_type, post_status,\n       COUNT(*) AS row_count,\n       COALESCE(SUM(OCTET_LENGTH(post_content)), 0) AS content_bytes\nFROM wp_posts\nGROUP BY post_type, post_status\nORDER BY post_type, post_status;<\/code><\/pre>\n
Liczba bajt\u00f3w obejmuje wy\u0142\u0105cznie pole tre\u015bci. Podczas bie\u017c\u0105cej edycji kolejne zapytania mog\u0105 przedstawia\u0107 r\u00f3\u017cne chwilowe stany bazy.<\/p>\n<\/div>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n