Hoe vaak moet ik mijn WordPress database optimaliseren?

Voor kleine informatiesites twee keer per jaar is voldoende. Voor actieve blogs of WooCommerce-webshops elke maand een lichte cleanup (transients, spam), en per kwartaal een grondigere pass (revisions, orphan meta, OPTIMIZE TABLE).

Kan een DB-optimalisatie mijn site breken?

Ja, als je zonder back-up DELETE-queries draait of autoload-rijen wist die een actieve plugin nodig heeft. Vandaar de regel: altijd eerst SELECT om te zien wat je gaat raken, altijd back-up, altijd staging voor productie.

Wat is autoload en waarom is het belangrijk?

Autoload-opties worden bij élke request geladen, vóór caching. Groot autoload betekent hoge TTFB voor alle bezoekers, ook die uit cache komen. Onder 500 KB is gezond, boven 800 KB is een alert, boven 1 MB is direct actie waard.

Is WP-Optimize genoeg of moet ik SQL leren?

Voor 80 procent van de sites is WP-Optimize met de standaardinstellingen voldoende. Voor de laatste 20 procent (autoload-audit, orphan meta die WP-Optimize niet vindt, specifieke plugin-restanten) helpt SQL of een webmaster die er even naar kijkt.

Wat met WooCommerce-databases?

Die hebben eigen valkuilen: Action Scheduler-tabellen die naar miljoenen rijen groeien, HPOS-migratie die dubbele meta achterlaat, subscription-plugins die eigen tabellen aanmaken. Start altijd met WooCommerce → Status → Tools, en pas daarna de generieke checks.

WordPress database optimaliseren: 8 concrete checks (2026)

Een gezonde WordPress-database heeft autoload-data onder de 800 KB en dat meten kost precies één query. WordPress database optimaliseren begint daar, niet bij een plugin die op één knop drukt. Deze technische how-to loopt acht checks door in de juiste volgorde, met concrete SQL-regels, WP-CLI-commando’s en veilige alternatieven waar plugins te grof zijn.

Ik doe dit zelf op sites vanaf de eerste dag dat de TTFB traag voelt. In mijn ervaring is de wp_options-tabel met autoload-data in negen van de tien gevallen de grootste hefboom, en tegelijk het minst besproken probleem in populaire tutorials. De rest van de checks (transients, revisions, orphan meta, spam, OPTIMIZE TABLE, scheduling) is aanvullend maar noodzakelijk.

phpMyAdmin met wp_options-tabel en autoload-audit

Waarom WordPress database optimaliseren de moeite waard is

Elke pagina-request in WordPress laadt eerst de wp_options-tabel met alle rijen waar autoload='yes'. Dat is voor caching, voor plugin-configuratie en voor site-instellingen. Het gebeurt vóór je cache-plugin überhaupt in beeld komt, dus vóór page-cache, object-cache of CDN.

Bij een schone site zit die autoload-set tussen 100 en 500 KB. Bij een site die twee jaar draait met wisselende plugins zie ik regelmatig 2 tot 5 MB. Dat verschil laadt bij elke request opnieuw, ook bij visitors die anders volledig uit cache zouden komen. Impact op TTFB: 100 tot 300 ms extra per pageload, gemakkelijk.

De tweede grote winst zit in verweesde rows: postmeta van verwijderde plugins, transients die nooit vervallen, revisions die eindeloos opstapelen. Individueel klein, samen soms honderdduizenden rijen. Ze maken elke SELECT langzamer omdat de storage engine meer data moet doorzoeken.

Voor de bredere context van laadtijd en Core Web Vitals verwijs ik naar mijn pagina over WordPress snelheid-optimalisatie. Databaseschoonmaak is één van de vijf grote hefbomen daar.

Check 1: back-up en meten waar je staat

Regel één: nooit een DELETE-query zonder back-up. Draai eerst een volledige dump.

Via SSH:

mysqldump -u user -p databasename > db-backup-2026-07-17.sql

Zonder SSH: phpMyAdmin, Export, kies “Custom”, vink alle tabellen aan, kies SQL-formaat, download. Bewaar dat bestand ergens buiten de server.

Meet daarna wat je hebt. Drie queries voor de basis:

SELECT SUM(LENGTH(option_value))/1024 AS autoload_kb
FROM wp_options WHERE autoload='yes';

SELECT COUNT(*) AS total_options FROM wp_options;

SELECT table_name, ROUND(data_length/1024/1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY data_length DESC LIMIT 10;

De eerste geeft je de autoload-grootte in kilobytes. De tweede telt totaal aantal opties (>500 is verdacht). De derde toont je top-10 zwaarste tabellen. Noteer alle drie voor de vergelijking na de opschoning.

Check 2: wp_options en autoload onder 800 KB houden

Als check 1 boven 800 KB uitkomt, is dit de eerste plek waar je winst haalt. Zie welke rijen de grootste blokken vormen:

SELECT option_name, LENGTH(option_value)/1024 AS kb
FROM wp_options WHERE autoload='yes'
ORDER BY kb DESC LIMIT 20;

Wat je in de top-20 vaak ziet:

Verwijderde plugins die hun instellingen niet hebben opgeruimd. Herkenbaar aan een prefix van een plugin-naam die je niet meer hebt.
Transients die als autoload=’yes’ zijn opgeslagen (dat hoort niet). Herkenbaar aan _transient_ of _site_transient_ in de naam.
Rogue cron-data of session-blobs.

De veilige aanpak per rij:

Zoek in Google op de option_name plus “wordpress plugin”. Kom je uit bij een plugin die je niet meer gebruikt: die rij kan weg.
Kom je nergens uit: zet autoload op no in plaats van te verwijderen. Dat behoudt de data maar laadt hem niet meer bij elke request.

UPDATE wp_options SET autoload = 'no' WHERE option_name = 'exact_option_name';

Verwijderen doe je alleen als je zeker weet wat het is. Voor de officiële uitleg over hoe WordPress opties inleest zie de WordPress-documentatie over de options-tabel.

Check 3: transients opruimen

Transients zijn tijdelijke cache-waarden. In gezonde staat vervallen ze zelf. In de praktijk laten veel plugins ze staan tot ze expliciet worden opgeruimd.

Via WP-CLI:

wp transient delete --expired
wp transient delete --all

De eerste ruimt alleen vervallen transients op (veilig). De tweede gooit alles weg, ook nog geldige. Dat is meestal ook prima omdat WordPress ze bij de volgende request opnieuw genereert, maar op een drukke site geeft dat een korte piek in DB-load.

Via SQL zonder WP-CLI:

DELETE FROM wp_options WHERE option_name LIKE '\_transient\_%';
DELETE FROM wp_options WHERE option_name LIKE '\_site\_transient\_%';

Draai deze op staging eerst en meet het verschil in aantal rijen.

Check 4: post revisions en auto-drafts beperken

Elke keer dat je een post opslaat, bewaart WordPress een revisie. Standaard onbeperkt. Een site met 500 blogposts en gemiddeld 20 revisies per post heeft 10.000 rijen extra in wp_posts, plus bijbehorende postmeta.

Zet in wp-config.php:

define('WP_POST_REVISIONS', 5);

Dat bewaart nog vijf revisies per post, wat voldoende is voor een “oeps”-moment. Op statische bedrijfssites zet ik het soms op 2.

Bestaande revisies opruimen via WP-CLI:

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

Of via SQL (met back-up):

DELETE FROM wp_posts WHERE post_type = 'revision';

Vergeet niet de bijbehorende postmeta op te ruimen (zie check 5).

Check 5: orphan postmeta en usermeta

Als je posts of gebruikers verwijdert, laat WordPress hun meta-rijen soms achter. Op sites met veel plugin-wissels stapelt dit snel op.

Meet eerst:

SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

Zie je 10.000+ orphan rijen: opruimen loont.

Delete-query (na SELECT-check):

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

Zelfde patroon voor usermeta:

DELETE um FROM wp_usermeta um
LEFT JOIN wp_users u ON um.user_id = u.ID
WHERE u.ID IS NULL;

Draai altijd eerst de SELECT-variant om aantallen te zien, en altijd op staging voor productie.

Check 6: spam, trashed comments en pingbacks

Comments-tabellen kunnen groeien zonder dat je het merkt, vooral als je Akismet niet actief hebt en spam blijft binnenkomen.

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

Of eenvoudiger via de plugin WP-Optimize (meer dan 1 miljoen actieve installs). Die combineert deze check en een aantal andere in een dashboard met tickboxen.

Check 7: OPTIMIZE TABLE draaien

Nadat je rijen hebt verwijderd, staat de fysieke tabel-structuur nog steeds op de oude grootte. Fragmentatie. OPTIMIZE TABLE reorganiseert de fysieke layout en geeft de schijfruimte terug.

Voor InnoDB gebeurt dit online (geen lock). Voor MyISAM (nog steeds op sommige oudere sites) lockt het de tabel. Check je storage engine eerst:

SELECT table_name, engine
FROM information_schema.TABLES
WHERE table_schema = DATABASE();

Voor alle tabellen tegelijk optimaliseren via WP-CLI:

wp db optimize

Of via phpMyAdmin: selecteer alle tabellen, kies “Optimize table” uit het dropdown. Meestal duurt dit een paar seconden voor kleine sites en enkele minuten voor grote.

Belangrijk: OPTIMIZE TABLE draai je ná de cleanup, niet ervoor. Anders reorganiseer je fragmenten die je vervolgens toch weg gaat gooien.

Check 8: automatische onderhoud plannen

Wat je één keer hebt opgeschoond, komt terug. Plan daarom een terugkerende cleanup.

WP-Optimize heeft een ingebouwde schedule (Instellingen → WP-Optimize → Scheduled clean-up). Realistische defaults voor de meeste sites:

Wekelijks: transients opruimen, spam wissen.
Maandelijks: revisions ouder dan 30 dagen, orphan meta.
Halfjaarlijks: OPTIMIZE TABLE.

Zet niet te veel op één schedule. Op WooCommerce-sites laat ik transients maandelijks draaien in plaats van wekelijks, omdat WC actief transients gebruikt voor productbeschikbaarheid en filters.

Voor bredere doorlopende hygiëne is een regelmatig WordPress-onderhoud meestal goedkoper dan losse uren per kwartaal.

Wanneer een webmaster het beter kan doen

Voor de meeste sites is deze checklist met WP-Optimize plus een handjevol SQL-regels in één tot twee uur klaar. Voor sites met verborgen valkuilen wordt het risico groter.

Concrete situaties waar direct contact met een webmaster loont:

WooCommerce met 100.000+ orders. De tabel wp_actionscheduler_actions en wp_wc_orders_meta_lookup kunnen naar tientallen GB groeien. WooCommerce heeft eigen tools onder Status → Tools die je eerst gebruikt.
Multisite-installaties waar per site-DB dezelfde opschoning nodig is.
Sites waar autoload > 5 MB en de bron onduidelijk is.
Sites waar een eerdere DELETE-query iets heeft gebroken en je terug wil naar back-up.

Voor die scenario’s zit ik op 95 euro per uur voor het reguliere databasewerk. Complex WooCommerce-cleanup of custom migratie-scripts zitten op 105 of 175 euro per uur, afhankelijk van of het spoed is. Ik werk in de source-code, geen dashboard-magie: SQL, phpMyAdmin, WP-CLI en tijd om per rij te kijken wat je wél wil bewaren.

Dezelfde patronen gelden voor andere stacks. Joomla heeft #__session en #__cache als bloat-tabellen. Drupal’s cache-tabellen (cache_*) kunnen fors worden. Laravel-projecten die “database” als session- of cache-driver draaien hebben hun eigen equivalent. Voor elk platform is de kern: back-up, meten, opruimen, meten opnieuw.