Je WordPress-site voelt traag aan, je hebt caching ingesteld en je hosting lijkt in orde - maar de laadtijden blijven tegenvallen. De kans is groot dat je database de bottleneck is. Database optimalisatie voor WordPress is een stap die veel site-eigenaren overslaan, terwijl het enorme impact kan hebben op je laadsnelheid.
In ons artikel over WordPress performance bottlenecks herkennen bespraken we al hoe je meet waar de vertraging zit. Vaak wijst de data naar dezelfde plek: de MySQL-database. In dit artikel duiken we dieper in de database zelf en leer je stap voor stap hoe je MySQL optimaliseert.
Waarom de database zo belangrijk is
Elke keer dat iemand een pagina opvraagt, voert WordPress tientallen tot honderden database-queries uit. Denk aan het ophalen van posts, metadata, opties, gebruikersgegevens en menu-items. Hoe een WordPress request precies werkt, hebben we eerder uitgelegd.
Als die queries traag zijn - door een slecht geconfigureerde database, ontbrekende indexes of opgehoopte rommel - merkt de bezoeker dat direct in de laadtijd. Vooral op pagina's die niet uit cache worden geserveerd, is de database vaak de langzaamste schakel.
Dit is ook de reden waarom object caching met Redis zo effectief is: het voorkomt dat dezelfde queries steeds opnieuw worden uitgevoerd. Maar Redis vervangt geen goed geoptimaliseerde database - het bouwt erop voort.
Stap 1: Analyseer je huidige database-performance
Voordat je iets wijzigt, moet je weten waar het probleem zit. Blindelings instellingen aanpassen kan meer kwaad dan goed doen.
Query Monitor installeren
De plugin Query Monitor toont precies welke database-queries worden uitgevoerd, hoe lang ze duren en welke component ze veroorzaakt. Installeer de plugin en bekijk de database-tab op een pagina die traag laadt.
Let op:
- Queries boven de 0,05 seconde - dit zijn potentiële knelpunten
- Duplicate queries - dezelfde query die meerdere keren wordt uitgevoerd
- Queries zonder index - MySQL markeert deze als "Full Table Scan"
Slow query log inschakelen
Op je server kun je de MySQL slow query log activeren. Dit logt alle queries die langer duren dan een drempelwaarde:
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
Analyseer het logbestand na een paar uur met mysqldumpslow om de meest voorkomende trage queries te identificeren:
mysqldumpslow -s t /var/log/mysql/slow.log
Stap 2: Database opschonen
WordPress-databases hebben de neiging om in de loop van de tijd vol te raken met data die je niet meer nodig hebt. Dit vertraagt queries en maakt de database onnodig groot.
Revisies beperken
WordPress slaat standaard onbeperkt revisies op van elke post. Een artikel met 50 revisies betekent 50 extra rijen in wp_posts en honderden rijen in wp_postmeta. Beperk dit in wp-config.php:
define('WP_POST_REVISIONS', 5);
Bestaande oude revisies verwijder je met WP-CLI:
wp post delete $(wp post list --post_type='revision' --format=ids) --force
Transients opruimen
Verlopen transients blijven in de wp_options-tabel staan totdat ze worden opgeruimd. Bij sites met veel plugins kunnen dit er duizenden zijn:
wp transient delete --expired
Als je Redis als object cache gebruikt, worden transients daar opgeslagen in plaats van in de database. Nog een reden om Redis te configureren.
Spam en prullenbak legen
Verwijderde posts, spam-reacties en verouderde logbestanden nemen ruimte in. Ruim ze regelmatig op:
wp comment delete $(wp comment list --status=spam --format=ids) --force
wp post delete $(wp post list --post_status=trash --format=ids) --force
wp_options opschonen
De wp_options-tabel is berucht als bottleneck. WordPress laadt bij elk request alle rijen waar autoload = yes op staat. Plugins die hun instellingen op autoload zetten zonder dat het nodig is, vertragen elke pageload.
Controleer hoeveel autoloaded data je hebt:
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';
Als dit meer dan 1 MB is, heb je een probleem. Zoek de grootste boosdoeners:
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
Vaak zijn dit achtergebleven opties van verwijderde plugins. Verwijder ze handmatig of zet autoload op 'no' voor opties die niet bij elke request nodig zijn.
Stap 3: Ontbrekende indexes toevoegen
Indexes zijn essentieel voor snelle queries. WordPress maakt standaard indexes aan op de belangrijkste kolommen, maar sommige plugins doen dit niet - en dat merk je bij grote tabellen.
Veelvoorkomende ontbrekende indexes
De wp_postmeta- en wp_usermeta-tabellen missen standaard een index op meta_value. Als je regelmatig zoekt of filtert op meta-waarden (bijvoorbeeld in WooCommerce), kan dit een enorm verschil maken:
ALTER TABLE wp_postmeta ADD INDEX meta_value_index (meta_value(191));
Let op: voeg alleen indexes toe die je daadwerkelijk nodig hebt. Elke index vertraagt schrijfacties (INSERT en UPDATE), omdat MySQL de index moet bijwerken.
EXPLAIN gebruiken
Met EXPLAIN kun je zien hoe MySQL een query uitvoert. Voer een trage query uit met EXPLAIN ervoor:
EXPLAIN SELECT * FROM wp_posts
WHERE post_type = 'product'
AND post_status = 'publish'
ORDER BY post_date DESC;
Kijk naar de kolom type. Als daar ALL staat, doet MySQL een full table scan - dat is bijna altijd een probleem op grote tabellen.
Stap 4: MySQL-configuratie optimaliseren
De standaard MySQL-instellingen zijn conservatief en bedoeld voor servers met weinig geheugen. Op een moderne VPS of dedicated server kun je aanzienlijk betere performance halen door de configuratie aan te passen.
InnoDB Buffer Pool Size
Dit is de belangrijkste instelling voor WordPress-performance. De InnoDB buffer pool is het geheugen dat MySQL gebruikt om data en indexes te cachen. Hoe meer er in het geheugen past, hoe minder MySQL naar de schijf hoeft te lezen.
Vuistregel: stel de buffer pool in op 70-80% van het beschikbare RAM als MySQL de enige service op de server is. Op een server die ook PHP en NGINX draait, is 50-60% een veiliger keuze.
# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
innodb_buffer_pool_size = 2G
Controleer hoe effectief je buffer pool wordt gebruikt:
SHOW STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW STATUS LIKE 'Innodb_buffer_pool_reads';
De verhouding tussen read_requests (reads uit geheugen) en reads (reads van schijf) is je buffer pool hit ratio. Deze moet boven de 99% liggen.
Query Cache (MySQL 5.7 en eerder)
In MySQL 5.7 was de query cache beschikbaar maar vaak contraproductief voor WordPress. Bij elke schrijfactie werd de hele cache voor de betreffende tabel gewist. MySQL 8.0 heeft de query cache volledig verwijderd.
Als je nog MySQL 5.7 draait, schakel de query cache uit:
query_cache_type = 0
query_cache_size = 0
Gebruik in plaats daarvan Redis als object cache - dat is een veel effectievere caching-laag.
Overige belangrijke instellingen
# Tijdelijke tabellen in geheugen houden
tmp_table_size = 64M
max_heap_table_size = 64M
# Meer gelijktijdige verbindingen toestaan
max_connections = 150
# Tabel-cache voor snellere toegang
table_open_cache = 4000
# InnoDB log-bestanden groter maken voor betere schrijfperformance
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M
# I/O-threads voor betere parallelle verwerking
innodb_read_io_threads = 4
innodb_write_io_threads = 4
MySQLTuner gebruiken
MySQLTuner is een script dat je MySQL-configuratie analyseert en concrete aanbevelingen doet:
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
perl mysqltuner.pl
Voer dit script uit nadat je server minimaal 24 uur draait, zodat het genoeg data heeft om zinvolle aanbevelingen te doen.
Stap 5: Tabelonderhoud uitvoeren
MySQL-tabellen kunnen na verloop van tijd gefragmenteerd raken, vooral bij veel DELETE- en UPDATE-operaties. Dit vergroot het bestand op schijf en vertraagt queries.
OPTIMIZE TABLE
OPTIMIZE TABLE wp_posts;
OPTIMIZE TABLE wp_postmeta;
OPTIMIZE TABLE wp_options;
Voor InnoDB-tabellen herbouwt OPTIMIZE TABLE de tabel en de indexes. Dit kan bij grote tabellen even duren - voer het uit tijdens een rustig moment.
Met WP-CLI kun je alle tabellen in één keer optimaliseren:
wp db optimize
Tabelformaat controleren
Controleer of al je tabellen het InnoDB-formaat gebruiken. Oudere WordPress-installaties hebben soms nog MyISAM-tabellen:
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'wordpress_db'
AND ENGINE != 'InnoDB';
Converteer MyISAM-tabellen naar InnoDB:
ALTER TABLE table_name ENGINE = InnoDB;
InnoDB is in vrijwel alle gevallen sneller dan MyISAM voor WordPress, omdat het row-level locking ondersteunt in plaats van table-level locking.
Stap 6: WooCommerce-specifieke optimalisaties
WooCommerce is bijzonder zwaar op de database. Producten, variaties, bestellingen en klantgegevens genereren enorme hoeveelheden metadata.
High-Performance Order Storage (HPOS)
Sinds WooCommerce 8.2 kun je HPOS activeren. Dit verplaatst bestellingen van de wp_posts- en wp_postmeta-tabellen naar dedicated tabellen met een geoptimaliseerd schema. Het resultaat: snellere order-queries en minder druk op de posts-tabellen.
Activeer HPOS via WooCommerce → Instellingen → Geavanceerd → Features.
Verlopen sessies opruimen
WooCommerce slaat klantsessies op in de wp_options-tabel. Bij drukke winkels kan dit de tabel flink laten groeien:
wp wc tool run clear_expired_transients
Product lookup tables
Zorg ervoor dat de WooCommerce product lookup tables zijn gegenereerd. Deze versnellen het filteren en zoeken van producten aanzienlijk. Controleer dit via WooCommerce → Status → Tools.
Monitoring en onderhoud
Database optimalisatie is geen eenmalige actie. Plan regelmatig onderhoud in:
- Wekelijks: transients en spam opruimen
- Maandelijks: revisies beperken,
OPTIMIZE TABLEuitvoeren - Elk kwartaal: MySQLTuner draaien en configuratie evalueren
- Bij performance-issues: slow query log analyseren en Query Monitor raadplegen
Combineer database-optimalisatie met de andere technieken uit onze serie. Full page caching verkleint het aantal requests dat de database bereikt, Redis cached de resultaten van herhaalde queries, en een goed geoptimaliseerde database zorgt ervoor dat de queries die wél worden uitgevoerd zo snel mogelijk zijn.
Zoals we in ons artikel over veelvoorkomende oorzaken van een trage WordPress-site al beschreven: performance is het resultaat van meerdere lagen die samenwerken. De database is daar een cruciale schakel in.
Veelgestelde vragen
Hoe vaak moet ik mijn WordPress database opschonen?
Voor de meeste sites is eens per maand voldoende. Bij sites met veel revisies, spam of WooCommerce-transacties kun je wekelijks opschonen. Automatiseer dit met WP-CLI of een plugin zoals WP-Optimize.
Wat is het verschil tussen InnoDB en MyISAM voor WordPress?
InnoDB ondersteunt row-level locking en transacties, wat het veel geschikter maakt voor WordPress. MyISAM lockt de hele tabel bij schrijfacties, wat tot vertragingen leidt. WordPress gebruikt sinds versie 5.5 standaard InnoDB.
Kan ik MySQL tuning doen op shared hosting?
Op shared hosting heb je geen toegang tot de MySQL-configuratie. Je kunt wel de database opschonen, queries optimaliseren en overbodige data verwijderen. Voor echte MySQL tuning heb je een VPS of dedicated server nodig.
Hoeveel verschil maakt database optimalisatie voor mijn laadtijd?
Bij sites met veel content of WooCommerce-producten kan database optimalisatie de TTFB met 30-60% verbeteren. Het effect is het grootst op pagina's die niet gecacht worden, zoals zoekresultaten en accountpagina's.