Als een klant trage beheerschermen, mislukte checkouts of willekeurige time-outs meldt, hebben bureaus niet de luxe om tientallen tabellen door te spitten of het gedrag van plugin’s te reverse-engineeren. Je moet de waarschijnlijke storingspunten snel herkennen en je aandacht richten op waar het belangrijk is.
In de praktijk zijn de meeste ernstige prestatie- en stabiliteitsproblemen terug te voeren op een klein aantal databasetabellen die in de loop van de tijd ongecontroleerd groeien. Deze tabellen veroorzaken geen problemen op nieuwe sites of sites met weinig verkeer, maar met jaren van content, plugins en gebruikersactiviteit zijn ze verantwoordelijk voor een onevenredig groot aantal crashes, langzame queries en dringende supporttickets.
Dit artikel richt zich op vijf WordPress database tabellen (en tabelpatronen) die je in het onderhoud actief in de gaten moeten houden, omdat ze de meeste kans hebben om echte prestatieproblemen te veroorzaken als sites groeien.
Waarom bureaus slechts 20% van de database hoeven te controleren
Het Pareto principe helpt bij het verklaren van veel operationele patronen, en het is ook van toepassing op het onderhoud van WordPress databases. Bureaus lopen niet gelijkmatig in de hele database tegen problemen aan. In plaats daarvan is een kleine subset van tabellen verantwoordelijk voor de meeste database-gerelateerde vertragingen, crashes en dringende support tickets.
Standaard WordPress installaties maken 12 standaard tabellen aan. Sommige tabellen, zoals wp_users, wp_links en taxonomietabellen, kunnen jarenlang werken zonder problemen te veroorzaken. Deze veroorzaken meestal niet de langzamere queries die sites laten crashen tijdens verkeerspieken.
De tabellen met een hoog risico hebben echter één kenmerk gemeen: als ze groot genoeg worden kunnen ze elke site uit de running halen. Een site met 100 berichten kan prima draaien met onbeperkte revisies. Diezelfde site, met 10.000 berichten en 300.000 revisie-items, zal waarschijnlijk een time-out krijgen bij elk bewerkingsscherm. Een e-commerce winkel met 50 producten zou goed moeten presteren, maar opschalen naar 5.000 producten kan ervoor zorgen dat pagina’s seconden nodig hebben om te laden.
Vijf databasepatronen die funest zijn voor WordPress sites op schaal
Laten we eens kijken naar vijf patronen die vaak voorkomen bij onderhoudswerk door bureaus.
Ze zijn niet meteen gevaarlijk op kleine sites, maar naarmate de inhoud, het verkeer en de activiteit van de plugin toeneemt, worden ze de meest voorkomende oorzaken van trage queries, time-outs en stabiliteitsproblemen.
wp_options: autoload bloat kan sites met veel verkeer laten crashen
De wp_options tabel slaat site-instellingen en plugin-configuraties op en bepaalt welke opties WordPress laadt bij elke pagina-aanvraag (inclusief pagina’s in de cache). Van de kolommen is autoload de belangrijkste:
WordPress laadt bij elke aanvraag eerst alle autoload opties in het geheugen. Sites met kleinere autoload footprints kunnen het verkeer normaal aan, maar als autoload groeit, verbruikt elke bezoeker meer geheugen dan je server per PHP proces toewijst.
Als de autoload te groot wordt (bijvoorbeeld meer dan 3 MB of meer), zie je trage beheerschermen, mislukte kassa’s tijdens de verkoop en 502 fouten.
De boosdoener is bijna altijd verweesde plugin-instellingen of tijdelijke cache-items die bekend staan als transients. Als autoload is ingeschakeld, kunnen sommige plugin opties die je verwijdert in de wp_options tabel blijven staan, wat betekent dat ze bij elke aanvraag worden geladen. Over een periode van maanden of jaren stapelen tientallen plugins zich op en worden niet gebruikte data geladen bij elke paginaweergave.
Met de SQL Console binnen Database Studio hierboven kun je een query uitvoeren om de autoload gegevensgrootte in bytes te controleren:
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Je kunt de console ook gebruiken om andere query’s uit te voeren, zoals het sorteren van de resultaten van de oorspronkelijke query.
Je plan hier zou moeten zijn om de resultaten te bekijken, te identificeren met welke grote autoload vermeldingen ze te maken hebben en ze op te ruimen (d.w.z. de rijen te verwijderen).
wp_postmeta: E-commerce sites kunnen crashen door metadata bloat
De tabel wp_postmeta slaat custom velden op voor berichten, pagina’s en producten. Telkens wanneer inhoud wordt opgeslagen, kunnen nieuwe metagegevens worden toegevoegd. Vooral plugins voegen vaak tientallen velden toe aan een enkele post of een enkel product.
WooCommerce bijvoorbeeld slaat productgegevens op in postmeta: variaties, voorraad, verzendgegevens en attributen. Een enkel product met variaties kan tientallen metagegevens genereren. Grote productcatalogi creëren potentieel miljoenen rijen postmeta.
Het resultaat van een uitdijende wp_postmeta tabel is bewerkingsschermen die moeite hebben met het laden van gegevens, productfilters die trager worden en zoekopdrachten die uitlopen bij het doorzoeken van enorme tabellen. Over het algemeen zijn fouten tijdens drukke periodes te wijten aan wp_postmeta bloat.
Met behulp van de SQL-console kun je query’s uitvoeren om overbodige gegevens te selecteren en verwijderen, zoals wp_options. Je zoekt naar aspecten zoals postmetatabellen van meerdere gigabytes, veel dubbele meta_keys en algemene niet-gebruikte metadata. De filteropties binnen Database Studio zijn hier ook nuttig:
Je kunt bijvoorbeeld sorteren op meta_key door op de kolompijl te klikken. Dit groepeert identieke sleutels bij elkaar zodat je patronen kunt herkennen, zoals sleutels van verwijderde plugins of ongebruikte aangepaste velden.
wp_posts: onbeperkte revisies zorgen voor crashes bewerkingspagina’s
De wp_posts tabel slaat inhoud en revisiegeschiedenis op. Standaard slaat WordPress elke wijziging op als een aparte database-invoer, dus regelmatige bewerking van inhoud genereert een aanzienlijke hoeveelheid extra gegevens. Sites met een uitgebreide inhoud en bewerkingsgeschiedenis kunnen duizenden revisie-items verzamelen.
In eerste instantie draait je site prima, maar door de vele opgeslagen revisies kunnen je beheerschermen traag laden tijdens het bewerken van berichten. WordPress slaat elke 60 seconden op tijdens het bewerken; autosaves kunnen ook een negatieve impact hebben omdat lange bewerkingssessies tientallen autosave entries creëren.
Je kunt de wp_posts tabel met revisies snel leegmaken (bijvoorbeeld):
Je kunt dan overschakelen naar de SQL console om een query uit te voeren en de revisies te verwijderen:
DELETE FROM wp_posts WHERE post_type="revision";
Het is een goed idee om het aantal revisies te vergelijken met je gepubliceerde berichten: verhoudingen van één cijfer zijn redelijk. Kijk ook of de revisies meer dan de helft van het totaal aantal berichten uitmaken, want dit duidt waarschijnlijk op bloat. Revisies die maand na maand toenemen suggereren de noodzaak voor het implementeren van limieten, die je kunt bereiken door een snelle bewerking van wp-config.php.
Plugin tabellen: formulieren en logs groeien tot je site crasht
Bijna elke plugin maakt aangepaste databasetabellen aan, maar het komt vaker voor bij formulier-, zoek- en beveiligingsplugins. Deze kunnen blijven groeien zonder dat er ingebouwd onderhoud nodig is.
Met name formulierplugins slaan standaard elke inzending permanent op. Als je sites dus jarenlang gestaag inzendingenverkeer ontvangen, verzamel je duizenden formuliervermeldingen. Bovendien groeien tabellen met logs nog sneller. Beveiligingsplugins registreren acties van bezoekers, analyseplugins houden paginaweergaves bij en debuggingprogramma’s registreren fouten.
Zoals bij veel problemen met databasetabellen, lopen pagina’s uit, maar je ziet ook langzame databaseback-ups en verminderde prestaties die niet correleren met verkeer. Het verband met database bloat zal niet altijd duidelijk zijn, omdat de symptomen zich op ongerelateerde gebieden voordoen.
Je zult op zoek willen gaan naar plugin tabellen die overeenkomen met of groter zijn dan de kerntabelgroottes van WordPress; hoe groter ze zijn, hoe belangrijker het is om ze te verkleinen. Een SQL query kan deze voor je opsporen:
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
Als er niet-gebruikte (orphaned) tabellen zijn, kun je ze veilig verwijderen. Maar als er tabellen zijn die groot genoeg zijn om te verkleinen, maar die nog steeds nodig zijn op je site, dan is het verstandig om hiernaar onderzoek te doen en eventueel contact op te nemen met de ontwikkelaar voor advies, ook al valt dit buiten het bestek van dit artikel.
Action Scheduler: mislukte taken stapelen zich op en laten de kassa crashen
Action Scheduler voert in wezen achtergrondtaken uit voor WordPress. Het zet taken in een wachtrij, verwerkt ze asynchroon en slaat voltooiingsrecords standaard permanent op.
Het gebruik van WooCommerce is een goede manier om te begrijpen hoe Action Scheduler problemen kan veroorzaken. Time-outs bij de betalingsgateway bijvoorbeeld resulteren in mislukte acties die in de database blijven staan en bij elke paginalading worden opgevraagd om te controleren of er nog werk aan de winkel is. Je kunt slechts één mislukte actie extrapoleren van de duizenden die een typische WooCommerce winkel per maand genereert.
Views van Database Studio kunnen je helpen deze mislukte acties te verwijderen:
Hier geef je de weergave een titel, kies je de tabel wp_actionscheduler_actions en klik je op de link Voorwaarde toevoegen. Hiermee kun je alleen mislukte acties laten zien, waardoor het veel eenvoudiger wordt om ze uit de database te verwijderen.
Hoe je belangrijke WordPress database tabellen kunt beheren in 10 minuten per maand
Voor de kosten van een paar minuten per maand kun je een jaar lang minder databasebeheer doen. Natuurlijk hoef je veel van de tabellen in je database niet te controleren of te beheren:
- De tabel
wp_usersveroorzaakt zelden problemen, tenzij je lidmaatschapsites beheert met miljoenen accounts. Gebruikersgegevens groeien meestal lineair zonder zich op te stapelen. - Taxonomietabellen (zoals
wp_terms,wp_term_taxonomy,wp_term_relationships) blijven vaak stabiel, ongeacht de grootte van de site.
Van de vijf probleemtabellen zijn grote wp_posts tabellen op inhoudssites typisch en te verwachten. Onthoud: werkelijke inhoud is geen bloat.
Je monitoringworkflow opzetten
Door je databasetabellen te exporteren kun je met de gegevens werken in andere toepassingen. Je kunt dit doen via het vervolgkeuzemenu More items voor elke tabel:
Je kunt echter veel bereiken in MyKinsta zonder te exporteren. Het beste gebruik van je tijd is om het opschonen te automatiseren en handmatig de statistieken van je database te bekijken. De weergaven van Database Studio kunnen je helpen bij het opzetten van je analyse.
Je kunt bijvoorbeeld een aangepaste weergave maken die wp_postmeta bewaakt en filters toevoegen voor specifieke meta_key patronen die je wilt volgen:
Met Database Studio kun je fragmenten maken en opslaan in de SQL Console, zodat je een SQL query kunt instellen om alle tabellen op grootte te sorteren en deze kunt openen wanneer je maar wilt:
Enkele van de grootste tabellen zijn wp_posts, wp_postmeta, en wp_options. Je zult alle tabellen willen onderzoeken die hoger in ranking zijn.
Welke monitoring je precies instelt, hangt af van je sites en behoeften. Hier zijn echter enkele gebieden waar je naar kunt kijken:
- Filter
wp_optionsop actieve autoloads, controleer dan de totale grootte (via SQL queries of exporteren naar CSV). Alles groter dan 1MB moet worden onderzocht. - Controleer de grootte van de tabel
wp_postmetain vergelijking met die van vorige maand, vooral op enorme toenames in grootte. - Je kunt post_type filteren binnen
wp_postsom revisies te vergelijken met posts. Als het nodig is, stel dan een limiet in binnenwp-config.php. - Voor Action Scheduler moet het aantal voltooide acties groter zijn dan het aantal lopende of mislukte acties.
Kortom, gebruik Database Studio om de weergaven, filters en querybestanden te maken die je vaak zult gebruiken. Zoek vervolgens naar ‘gevaarlijke’ statistieken en gebruik dan andere tools om eventuele opschoning te automatiseren. Het commando wp transient delete WP-CLI kan je bijvoorbeeld helpen om ongewenste transiënten in de database op te ruimen.
Van reactieve oplossingen naar proactief database onderhoud
De database problemen waar bureaus het vaakst mee te maken hebben zijn niet zeldzaam of onvoorspelbaar. Ze zijn het resultaat van bekende patronen. Het verschil tussen reageren op deze problemen en ze voorkomen komt neer op focus.
Je hoeft niet elke tabel te inspecteren of elke query te controleren. Je moet weten welke delen van de database continue aandacht verdienen en hoe je vroegtijdige waarschuwingssignalen kunt herkennen voordat ze uitmonden in storingen of dringende ondersteuningsverzoeken.
Voor onderhoudsbureaus verandert dit de manier waarop databasewerk in je workflow past. In plaats van database opschoning te behandelen als een eenmalige fix nadat er iets kapot is gegaan, wordt het een lichte, herhaalbare controle.
Als je tegen een databaseprobleem aanloopt dat je niet kunt oplossen, vooral een probleem dat alleen onder belasting opduikt, is het belangrijk om de juiste ondersteuning te hebben. Voor sites die worden gehost op Kinsta is ons ondersteuningsteam 24/7 beschikbaar om je te helpen.
