En WordPress-databas som aldrig städas kan växa till hundratals megabyte – eller mer – utan att du märker det förrän sidan börjar hacka. Det händer inte över en natt, men det händer.
Jag ser det regelbundet hos kunder som haft sin webb igång i tre, fyra år utan att någon tittat under huven.
Vad som faktiskt tar plats
Det är nästan alltid samma tre syndare:
Post-revisions. WordPress sparar en ny version av varje inlägg eller sida varje gång du klickar spara. Har du redigerat en sida 40 gånger finns det 40 revisions i databasen. Multiplicera med hundra sidor och du förstår problemet.
wp_options och autoload-data. Det här är den elakaste. Plugins dumpar inställningar i wp_options-tabellen och sätter ofta autoload=yes – vilket innebär att datan laddas vid varje sidladdning, oavsett om den används. Avinstallerar du pluginet ligger datan kvar. För alltid, om ingen rensar.
Skräptransient. WordPress och plugins använder transients för temporär cache. De ska ha ett utgångsdatum, men trasig kod skapar transients utan det. De samlas på hög i wp_options.
Hur du kollar storleken
LoggaGin i phpMyAdmin (finns i de flesta kontrollpaneler). Klicka på din WordPress-databas och sortera tabellerna på storlek.
Titta extra på:
wp_options– bör sällan vara mer än 1–2 MB om databasen är välsköttwp_posts– stor är OK om du har mycket innehåll, men kolla antalet revisionswp_postmeta– kan bli enorm på WooCommerce-sajter med gamla ordrar
Ett enkelt SQL-kommando i phpMyAdmin visar hur mycket autoload-data du drar:
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload='yes';
Mer än 1 MB autoload-data och du har ett problem som påverkar laddtiderna direkt.
Att begränsa revisions
Enklaste åtgärden. Lägg till den här raden i wp-config.php:
define('WP_POST_REVISIONS', 5);
Det begränsar framtida revisions till fem per inlägg. Det raderar inte befintliga – det kräver antingen ett plugin eller ett SQL-kommando.
För att radera gamla revisions manuellt:
DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);
Gör det i phpMyAdmin, och ta en backup först. Alltid.
Städa wp_options
Här är det svårare att göra manuellt om du inte vet vad du letar efter. Det enklaste är pluginet WP-Optimize eller Advanced Database Cleaner. De visar autoload-data sorterat på storlek och låter dig ta bort rader från avinstallerade plugins.
Vara försiktig med att radera rader du inte känner igen. Vissa plugins namnger sina nycklar kryptiskt. Googla nyckeln om du är osäker.
Ett mönster jag ser ofta: kunder har testat fem olika formulär- eller cache-plugins genom åren och avinstallerat fyra av dem. Alla fyra har lämnat data i wp_options. Ibland flera megabyte.
WooCommerce och gamla ordrar
Har du en butik? Då är wp_postmeta och wp_wc_orders (eller den äldre wp_posts-baserade orderstrukturen) de tabeller du behöver hålla koll på.
WooCommerce sparar ordrar med all metadata – kundinfo, produktrader, fraktdata. En gammal butik med tiotusentals ordrar kan ha en databas på gigabyte. Det finns ett inbyggt verktyg i WooCommerce under Status → Verktyg → Databasuppdatering för att optimera, men för seriös rensning behöver du ofta ett tilläggsverktyg eller göra det manuellt.
Hur ofta?
En gång per kvartal är rimligt för de flesta. Mer om du publicerar mycket eller har en aktiv butik. Automatisk optimering via ett plugin (WP-Optimize kan schemaläggas) funkar bra om du litar på att det körs utan att ställa till det.
Jag rekommenderar att du kör en fullständig backup innan varje databasrensning, oavsett hur rutinmässigt det känns. Databasbuggar är sällsynta men inte omöjliga, och återställning går snabbt om du har en färsk kopia.
Har du ett WordPress supportavtal hos oss ingår databasoptimering i det löpande arbetet – du behöver inte hålla koll på det själv. Eller börja med att köra vårt gratis webbtest om du vill se hur din webb mår just nu.
