Guide til optimalisering av WordPress-database (2026-utgave)

WordPress lagrer alt i en MySQL- (eller MariaDB-) database. Over tid “blåses” denne databasen opp og samler unødvendige data, noe som kan redusere hastigheten på spørringer og hele nettstedet. En større database betyr lengre sikkerhetskopieringstider, tregere SELECT-spørringer og økt Time To First Byte (TTFB).

I denne omfattende guiden for utviklere vil vi gå gjennom avansert databaseoptimalisering – fra enkel rengjøring til spørringsanalyse og InnoDB-konfigurasjon.

Hvorfor databaseoptimalisering er kritisk i 2026

I 2026, når en TTFB under 100ms er standarden, er en “tung” database et anker for nettstedet ditt. Selv om du har en superrask server (PHP 8.4, NVMe), kan dårlig optimaliserte SQL-spørringer drepe ytelsen.

Hovedårsaker til databaseproblemer:

1. Bloatware (Overskuddsdata): Innleggsrevisjoner, kommentarspam, foreldreløse metadata.
2. Autoloaded Options: Data lastet ved hver sideoppdatering, selv om de ikke brukes.
3. Manglende indekser: Spørringer som må skanne hele tabellen (Full Table Scan).
4. Tabellfragmentering: Hull i dataene som øker filstørrelsen på disken.

Del 1: Databasehygiene (rengjøring)

La oss starte med å fjerne søppelet. Du kan gjøre dette med et programtillegg (WP-Optimize), men som utvikler bør du vite hvordan du gjør det “manuelt” ved hjelp av SQL eller WP-CLI.

1. Innleggsrevisjoner (post revisions)

Hver gang du klikker “Lagre utkast”, opprettes en ny kopi av innlegget. Med lange redigeringsøkter kan du ha hundrevis av revisjoner for en enkelt artikkel.

SQL-spørring for å sjekke revisjonsantall:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

Slette revisjoner (SQL):

DELETE FROM wp_posts WHERE post_type = 'revision';

Anbefalt: Bruk WP-CLI (Sikrere):

wp post delete $(wp post list --post_type='revision' --format=ids) --force

2. Slette spam og søppel

Det er ingen vits i å beholde spam eller slettede innlegg.

SQL:

DELETE FROM wp_comments WHERE comment_approved = 'spam';
DELETE FROM wp_comments WHERE comment_approved = 'trash';

3. Transients (midlertidige data)

Transients er hurtigbuffer lagret i databasen (wp_options). Noen ganger blir ikke utløpte transients fjernet automatisk.

SQL for å slette utløpte transients:

DELETE FROM wp_options WHERE option_name LIKE ('_transient_timeout%') OR option_name LIKE ('_transient_%');

WP-CLI (Beste metode):

wp transient delete --all

Del 2: Autoloaded options (den stille ytelsesdreperen)

Tabellen wp_options inneholder en autoload-kolonne. Hvis satt til yes, lastes det alternativet ved hver sideinnlasting. Programtillegg etterlater ofte søppel her etter avinstallering.

Hvordan diagnostisere problemet?

Sjekk hvor mye data (i bytes) som lastes automatisk:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload = 'yes';

Hvis resultatet overstiger 800 KB - 1 MB, har du et problem.

Hvordan finne de største alternativene?

SELECT option_name, LENGTH(option_value) as option_size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size DESC
LIMIT 10;

Du vil ofte finne gamle data fra cache-programtillegg, byggere eller logger her. Hvis programtillegget ikke lenger brukes, kan du trygt slette disse alternativene eller endre autoload til no.

Del 3: InnoDB vs MyISAM

I 2026 bør du ikke lenger bruke MyISAM-motoren. InnoDB er standarden, som tilbyr:

• Låsing på radnivå (Row-level locking): MyISAM låser hele tabellen ved skriving.
• ACID-transaksjoner: Datasikkerhet.
• Foreign Keys: Relasjonskonsistens.

Sjekk tabellmotor:

SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'ditt_databasenavn';

Konverter til InnoDB:

Hvis du finner MyISAM-tabeller, konverter dem:

ALTER TABLE wp_posts ENGINE=InnoDB;
ALTER TABLE wp_comments ENGINE=InnoDB;
ALTER TABLE wp_options ENGINE=InnoDB;
-- og så videre for alle tabeller

Del 4: Indeksering (avansert)

WordPress har vanligvis gode standardindekser, men programtillegg legger ofte til sine egne tabeller uten riktige indekser. Manglende indeks på en WHERE- eller JOIN-spørring betyr at MySQL må skanne hver rad i tabellen.

Eksempel: Tregt søk i WooCommerce

Hvis du har en butikk med 100 000 ordrer, og et programtillegg søker etter ordrer med meta_key uten indeks, kan siden “Min konto” ta 10 sekunder å laste.

Løsning: Legg til indekser i kolonner du ofte søker eller sorterer etter.

CREATE INDEX idx_meta_key_value ON wp_postmeta (meta_key(191), meta_value(50));

(Merk: Indeksering av meta_value er vanskelig fordi det er TEXT. Unngå å søke etter meta_value hvis mulig).

Del 5: Forebygging (konfigurere wp-config.php)

I stedet for å rengjøre konstant, er det bedre å ikke forsøple. Konfigurer WordPress klokt.

Begrens revisjoner

Legg til i wp-config.php:

// Begrens til 5 nylige versjoner
define( 'WP_POST_REVISIONS', 5 );

// Tøm søppelbøtten hver 7. dag (standard er 30)
define( 'EMPTY_TRASH_DAYS', 7 );

// Øk autosave-intervall (færre AJAX-forespørsler i redigering)
define( 'AUTOSAVE_INTERVAL', 300 ); // sekunder

Deaktiver filredigering

For sikkerhet og hygiene:

define( 'DISALLOW_FILE_EDIT', true );

Del 6: Overvåkingsverktøy (query monitor)

Ikke gjett hva som bremser nettstedet. Installer programtillegget Query Monitor. Etter installasjon vil du i admin-linjen se sidegenereringstid og antall SQL-spørringer.

1. Klikk på statistikken i linjen.
2. Gå til fanen “Queries”.
3. Sorter etter “Time”.

Hvis du ser en spørring som tar 0,5s eller mer – det er ditt optimaliseringsmål. Det kommer ofte fra et dårlig skrevet programtillegg (“Nylig viste produkter”, “Besøksteller”, etc.).

Oppsummering: Sjekkliste for optimalisering

1. Sikkerhetskopi: Ta alltid sikkerhetskopi før du arbeider med databasen.
2. Motor: Sørg for at alle tabeller er InnoDB.
3. Autoload: Sjekk autoloaded options-størrelsen (sikt mot < 800KB).
4. Rengjøring: Fjern revisjoner, spam og utløpte transients.
5. Indekser: Sjekk om tunge spørringer bruker indekser.
6. Forebygging: Konfigurer wp-config.php for å begrense søppelproduksjon.

Når databasen din er slank og rask, bruker PHP mindre minne, og brukerne får innhold umiddelbart. Dette er grunnlaget for moderne WordPress.