Mijn database vertraagt mijn site. Moet hij een eigen server krijgen?

Je webwinkel laadt 's ochtends vroeg prima en sleept zich rond lunchtijd voort. Het WordPress-dashboard doet een paar seconden over het openen van een product, en een snelheidstest geeft je een redelijke score met een vage opmerking over de reactietijd van de server. Iemand op een forum zegt dat de database het probleem is, en iemand anders zegt dat een grotere server het oplost.

De eigen WordPress-databasegids van DreamHost wijst erop dat online snelheidstools je database niet kunnen bereiken. Een site kan dus goed scoren en toch trage queries draaien. Je hebt een test nodig die in de pagina kijkt terwijl die wordt opgebouwd. Dat doet Query Monitor.

We gaan stap voor stap: zoek uit of MySQL het trage onderdeel is, los op wat je kunt op de server die je al hebt, en beslis dan of een privé-MySQL-server de moeite waard is en wat er verandert als je data verhuist.

Controleer of de database het trage onderdeel is

Je kunt elke controle hieronder uitvoeren vanuit je panel en WordPress, zonder beheerdersrechten op de MySQL-server. Geen enkele controle verandert iets aan je site, behalve dat je één plugin installeert.

1. Zoek uit op welke MySQL-server je zit, en waar

   Open de pagina MySQL Databases in je panel en bekijk de servernaam naast elke database. De handleiding van DreamHost over databaselogs legt de namen uit: een naam die begint met iad1 is een gedeelde MySQL-server, sql gevolgd door een getal is een privé-MySQL-server en ds is een dedicated server. Begint die van jou al met sql, dan zit je op een privéserver en gelden de signalen om te kopen verderop niet voor jou. Open daarna de pagina Data Centers in het panel. Je webserver en MySQL-server horen in hetzelfde datacenter te staan om netwerkvertraging te beperken. Is dat niet zo, dan kan de support ze verhuizen.

2. Installeer Query Monitor en vergelijk twee getallen

   Query Monitor is een gratis plugin die elke databasequery op een pagina toont en die groepeert per plugin, thema of WordPress-core. Log in als beheerder en open een pagina die traag aanvoelt. Het menu van de plugin in de beheerwerkbalk toont de generatietijd van de pagina en de totale tijd van de SQL-queries, allebei in seconden. Vergelijk die twee. Is de querytijd maar een klein deel van de generatietijd, dan houdt iets anders dan de database de pagina op, zoals HTTP-aanroepen of het renderen van blokken.

3. Zoek de plugin en de query's die de tijd kosten

   Open het paneel Queries by Component. Het is gesorteerd op totale tijd, dus de plugin of het thema met de meeste databasetijd staat bovenaan. Volgens de maker van de plugin begin je daar als een site traag aanvoelt. Query Monitor markeert een query als traag zodra die langer duurt dan 0,05 seconden. Ook duplicaten worden gemarkeerd. Die betekenen meestal dat code een query in een lus uitvoert, terwijl de code ook één keer zou kunnen opvragen en het resultaat cachen.

4. Laad dezelfde pagina op een rustig en een druk uur

   Query Monitor houdt geen geschiedenis bij. Schrijf de cijfers dus op. Laad de trage pagina op een rustig moment en daarna nog eens op je drukste uur, en vergelijk de totale querytijd en de tijden van dezelfde trage queries. Het artikel van DreamHost over betere databaseprestaties noemt vertraging bij piekverkeer als een van de signalen dat de database de bottleneck is, en raadt aan om ook het gebruik van je server tijdens piekuren te controleren.

5. Bekijk je gebruiksgrafiek voor dezelfde uren

   Bij Webhosting toont de pagina Servers & Usage CPU, RAM en opslag als Low, Medium of High over de afgelopen dag, week of twee weken. Volgens de gebruiksgids van het Help Center worden CPU en RAM op de webserver gedeeld tussen accounts, maar tonen de grafieken alleen het gebruik van jouw account. Een waarde van High wijst naar je eigen PHP en plugins. Een normale waarde vertelt je dat jouw account niet de zware gebruiker is, maar niet hoe druk de rest van de server is.

Koppel nu wat je zag aan een waarschijnlijke oorzaak:

Wat gedeelde MySQL je niet laat zien

Op gedeelde MySQL kun je de logs van de server niet inzien, ook de slow query logs niet, en volgens de gids van DreamHost over databaselogs kan de support ze ook niet voor je ophalen. Je MySQL-gebruiker heeft ook geen PROCESS-privilege, dus een proceslijst toont alleen je eigen queries, en de gebruiker kan geen SET GLOBAL uitvoeren om serverinstellingen te wijzigen.

Het slow query log waarover je in de handleiding van MySQL leest, is hier dus buiten bereik: het staat standaard uit en alleen iemand met beheerdersrechten op de server kan het aanzetten. De standaardlimiet is 10 seconden. Volgens dezelfde gids in het Help Center kan de support van DreamHost op verzoek logs voor je ophalen van een privé-MySQL-server. Op een dedicated server krijg je zelf toegang tot de configuratiebestanden van MySQL.

Los het eerst op waar het zit

Dit werkt allemaal op je huidige plan, nog voordat je ergens voor betaalt.

Bekijk de trage queries met EXPLAIN. Kopieer een trage query uit Query Monitor. Zet EXPLAIN ervoor en voer hem uit in phpMyAdmin. De documentatie van MySQL over het EXPLAIN-statement beschrijft hoe het het plan toont dat MySQL gaat gebruiken, inclusief welke indexen het leest, en EXPLAIN ANALYZE voert de query echt uit en meldt de werkelijke tijd. De gedeelde MySQL van DreamHost geeft je het INDEX-privilege, dus je kunt een index toevoegen als het plan laat zien dat MySQL een hele tabel doorzoekt. Noteer elke index die je aan een WordPress- of WooCommerce-tabel toevoegt, zodat je na updates kunt controleren of hij er nog is.

EXPLAIN SELECT option_name FROM wp_options
WHERE autoload = 'yes' OR autoload = 'on';

Ruim de eigen tabellen van WordPress op. De opschoonstappen van DreamHost voor WordPress-databases draaien via SSH met WP-CLI. Ze verwijderen transients, optimaliseren de tabellen, beperken berichtrevisies en schonen de tabellen postmeta en commentmeta op. Controleer eerst je autoload-grootte, want WordPress laadt die opties bij elk verzoek, en onder ongeveer 600 KB is goed voor de meeste servers. Deze commando's komen uit dat artikel:

wp transient delete --all
wp db optimize
wp db query "SELECT SUM(LENGTH(option_value)/1048576) as 'Autoload(MB)' FROM $(wp config get table_prefix)options WHERE autoload='yes' or autoload='on';"

Tabellen met veel overhead vertragen queries en kunnen ervoor zorgen dat de webserver een time-out krijgt terwijl hij op een antwoord wacht. De optie Optimize table in phpMyAdmin ruimt de overhead op, zoals de gids van DreamHost over traagheid uitlegt.

Zet caching aan. De eigen prestatiedocumentatie van WordPress noemt caching de snelste manier om de prestaties te verbeteren. Een plugin voor paginacache serveert berichten en pagina's als statische bestanden, zodat de meeste bezoeken MySQL nooit bereiken. Voeg daarna een objectcache toe.

Voor gedeelde hosting beschrijft het Help Center van DreamHost de plugin Docket Cache als een bestandsgebaseerde persistente objectcache, en OPcache, die de plugin nodig heeft, staat al aan. Wil je je helemaal niet met caching bezighouden, dan regelt WordPress-hosting met ingebouwde caching van DreamHost het op serverniveau.

Instellingen op serverniveau, zoals het geheugen van InnoDB, zijn een aparte klus. Die behandelen we in ons artikel over MySQL afstemmen op een VPS.

Tekenen dat de database een eigen server nodig heeft

DreamHost omschrijft gedeelde MySQL als geschikt voor geoptimaliseerde databases en standaard websiteprestaties, en MySQL VPS als bedoeld voor klanten die een snellere databaserespons nodig hebben of gedeelde MySQL ontgroeid zijn. De MySQL VPS-pagina noemt in de FAQ ook de grens van delen: Een gedeelde server kan bij ongewoon veel verkeer mogelijk tot prestatieknelpunten leiden.

Trage queries alleen betekenen nog niet dat gedeelde MySQL de verkeerde plek is. Kijk dus pas naar een privéserver als je de oplossingen hierboven hebt doorgevoerd en deze signalen toch blijven opduiken:

• Dezelfde queries zijn trager op je drukke uur. Je notities van rustige en drukke momenten uit Query Monitor laten zien dat dezelfde queries duidelijk langer duren bij veel verkeer, zelfs na opschonen en cachen.
• Verbindingsfouten blijven terugkomen nadat je de hostnaam hebt gecontroleerd en de support de server heeft nagekeken. Een MySQL VPS geeft je databases resources die ze niet met andere gebruikers delen. DreamHost publiceert voor geen van beide soorten servers verbindingslimieten, dus we kunnen je geen getal geven.
• Je app heeft triggers of stored routines nodig. Volgens het Help Center van DreamHost kun je op gedeelde MySQL geen nieuwe triggers maken en zijn stored routines daar niet beschikbaar, terwijl een MySQL VPS beide ondersteunt.
• Je hebt MySQL-logs nodig om te debuggen. Volgens het Help Center van DreamHost kan de support ze ophalen van een privé-MySQL-server.

Past geen van deze signalen, blijf dan waar je bent. Een antwoord op Stack Overflow uit 2009 pleit voor blijven:

Het hoogst gewaardeerde antwoord in dezelfde thread, met 188 stemmen, betoogt het omgekeerde op grond van schaalbaarheid en prestaties. Laat je eigen cijfers van drukke uren de doorslag geven.

Wat er verandert als de database verhuist

Ben je bang dat een externe database een extra netwerkstap toevoegt? Je site heeft er al een. Het MySQL-overzicht van DreamHost laat zien waar elk type MySQL-server draait:

Daarom zegt het Help Center van DreamHost dat klanten nooit localhost als databasehost moeten gebruiken. Een MySQL VPS toevoegen verandert alleen waar de database staat; je site bereikt hem nog steeds via het netwerk. De forumverhalen over een externe database gaan over andere opstellingen. In een thread op Server Fault gebruikte een site in de VS een database in Azië en reageerde die erg traag, tot de database naar een lokale server verhuisde. Die vertraging kwam door de afstand, en daarom staat de datacentercontrole als eerste in de stappen hierboven.

De verhuizing zelf regel je vanuit het panel:

1. Maak een back-up van elke database
   Exporteer eerst een kopie van elke database.
2. Voeg een MySQL VPS toe via het panel

   Heb je al een VPS op je account, gebruik dan Add Service+ op de pagina Servers & Usage. Zo niet, open dan de pagina MySQL Databases en klik op Turn on a MySQL VPS!. De stappen van DreamHost om een MySQL VPS toe te voegen behandelen beide routes. Het inrichten kan een paar uur duren.

3. Kies een rustige nacht voor de verhuizing

   Volgens het Help Center verhuist DreamHost om middernacht Pacific-tijd alle databases op je account naar de nieuwe server, en toont het panel dit als een samenvoeging. Er staat niet bij of je site tijdens de verhuizing offline gaat of hoe lang de verhuizing duurt. Voeg de server toe op een dag waarop middernacht Pacific-tijd een rustig moment is voor je bezoekers, en vraag het vooraf aan de support als je zekerheid nodig hebt.

4. Controleer op achterblijvers

   Sommige databases kunnen verdeeld raken over de oude gedeelde server en de nieuwe. Met de knop Move my databases! op de pagina MySQL Databases breng je ze weer samen op één plek.

5. Controleer de hostnaam en test opnieuw

   Open de pagina MySQL Databases en vergelijk de hostnaam die daar bij elke database staat met DB_HOST in je configuratiebestand. Wijken ze af, pas DB_HOST dan aan zodat die overeenkomt met het panel. Een nieuw toegevoegde hostnaam kan tot 4 uur nodig hebben voordat hij werkt, omdat databasehostnamen DNS-namen zijn. Laad daarna je trage pagina's op dezelfde rustige en drukke uren en vergelijk de tijden met je aantekeningen.

Na de verhuizing werken een paar dingen anders:

• Je krijgt nog steeds geen root- of SSH-toegang. MySQL VPS is beheerd: DreamHost regelt het onderhoud, de beveiligingspatches en de updates van het besturingssysteem, en DreamHost blijft de MySQL-instellingen bepalen. Heb je de configuratiebestanden nodig, of verplaatst je app grote hoeveelheden data van en naar MySQL, dan verwijst DreamHost je naar een dedicated server, waar MySQL op dezelfde machine draait.
• Het RAM kan later groeien. Je kunt het RAM op elk moment verhogen vanuit het panel, en volgens het Help Center krijg je een tegoed naar rato voor het oude abonnement.
• Je kunt zien of je data in het geheugen past. Voer SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; uit en bereken 1 min Innodb_buffer_pool_reads gedeeld door Innodb_buffer_pool_read_requests. Op een server die alleen je databases draait, is dat het aandeel leesacties dat uit het geheugen komt: het getal in de tabel hieronder. Op onze test-MySQL kon een gebruiker met rechten op één database deze tellers wel lezen, maar SHOW ENGINE INNODB STATUS niet.
• Teruggaan kent een groottelimiet. Heb je geen dedicated server, dan moet elke database op de MySQL VPS kleiner zijn dan 3 GB voordat je de server vanuit het panel kunt verwijderen. Daarna kies je een server om naartoe te verhuizen, en DreamHost zet je data binnen 24 uur over naar de gedeelde databaseserver.

Welke optie past

Kies de route die past bij wat je controles lieten zien.

Kies je voor de MySQL VPS, begin dan met VPS business. De pagina van DreamHost noemt dit plan Gebouwd voor kleine bedrijven, en volgens de abonnementenlijst in het panel van DreamHost krijg je 1 GB RAM en 20 GB opslag. VPS basic is een stap lager. De pagina noemt VPS basic Voor nieuwe en kleine websites, wat past bij een kleine site die vooral verhuist vanwege triggers, routines of logs. VPS basic heeft volgens de abonnementenlijst van DreamHost 500 MB RAM. In onze test liep MySQL met de standaardinstellingen onder belasting vast op een limiet van 512 MB, zelfs met een kleine database. DreamHost configureert MySQL zelf op elk abonnement en publiceert de instellingen van VPS basic niet, dus vraag de support waarvoor het geschikt is voordat je er een drukke database naartoe verhuist.

Zoek voordat je kiest op hoe groot je databases zijn. De handleiding van DreamHost voor het optimaliseren van een database geeft hiervoor deze query. Maak via SSH verbinding met de database en voer hem uit om de data en indexen van elke database in MB te zien:

SELECT table_schema "database", sum(data_length + index_length)/1024/1024 "size in MB" FROM information_schema.TABLES GROUP BY table_schema;

Ligt het totaal ruim boven het RAM van het abonnement, dan kan MySQL niet alles in het geheugen houden. Begin dan een maat groter.

Hoeveel data 1 GB aankon op onze test-VM

We hebben die vuistregel getest voordat we erop gingen leunen. Op een test-VM gaven we MySQL 8.4 een harde geheugenlimiet ter grootte van elk MySQL VPS-abonnement, met de cache op ongeveer de helft daarvan, en draaiden we een constante, webachtige belasting op drie databasegroottes. De tabel laat zien hoeveel leesacties MySQL uit het geheugen beantwoordde en hoe lang de traagste 5% van de transacties duurde. Elke transactie is een reeks lees- en schrijfacties, vergelijkbaar met één paginaweergave.

Een database kleiner dan de helft van het RAM van het abonnement bleef snel. Zodra de data groter werd dan het RAM, werden de traagste transacties trager: 18,6 ms voor de database van 1,8 GB op 1 GB, tegenover 8,7 ms één abonnement hoger. Bij 4,6 GB op 1 GB kon MySQL de belasting helemaal niet bijhouden. Een limiet van 512 MB, dicht bij de 500 MB van VPS basic, was te klein voor MySQL met de standaardinstellingen: het gebruikte zo'n 470 MB voordat er ook maar één query draaide, en elke run liep vast op de limiet.

Dit zijn onze testinstellingen, niet die van DreamHost. DreamHost configureert MySQL op elk abonnement en publiceert de cachegrootte niet, en op een MySQL VPS kun je de serverinstellingen van MySQL niet wijzigen. Zie de tabel als richtlijn voor hoeveel data elke geheugengrootte comfortabel aankan. De volledige test, met elke cachegrootte die we hebben geprobeerd, staat in onze gids over hoeveel RAM MySQL nodig heeft.

We kunnen je niet vertellen hoeveel bezoekers elk abonnement aankan, want dat hangt meer af van je query's dan van je grootte. Lopen je tijden op het drukste uur weer op naarmate je data groeit, verhoog dan het RAM vanuit het panel.

Hoe we de geheugenvraag hebben getest

De geheugencijfers zijn door DreamHost gemeten op een test-VM (arm64), niet op een server van DreamHost. Een harde geheugenlimiet verving het RAM van elk MySQL VPS-abonnement. We deden de run op 19 oktober 2026 voor onze gids over RAM-dimensionering, en deze pagina hergebruikt hem. De VM draaide Ubuntu 24.04 onder Colima op een Mac, met 2 vCPU en zonder swap. MySQL 8.4.11 draaide vanaf de officiële Docker-image met de standaardinstellingen, behalve de cachegrootte. sysbench genereerde een gemengde lees- en schrijfbelasting gericht op een drukke kern van rijen, met 8 threads op een constante 360 transacties per seconde en een meetvenster van 3 minuten na een opwarmfase.

De MySQL VPS-pagina vermeldt MySQL 8.0, en volgens het Help Center-artikel Using reserved words in MySQL 8 van DreamHost kun je op een VPS contact opnemen met de support om een upgrade naar MySQL 8.4 aan te vragen. Wij hebben 8.4 getest, dus een server die nog op 8.0 draait kan iets afwijken.

Wat we niet hebben getest: de eigen MySQL VPS-instellingen van DreamHost, gedeelde MySQL, Query Monitor-tijden op een echt account, het netwerk tussen een webserver en een MySQL VPS, WordPress- of WooCommerce-tabellen en hoe lang de verhuizing duurt. Elke cel is één keer gedraaid. De diagnosestappen en productdetails komen uit het Help Center en de productpagina's in de bronnen.

Veelgestelde vragen over een trage database