Hoeveel RAM heeft MySQL nodig, en hoe groot moet de bufferpool zijn?

Deze gids helpt je de juiste grootte te kiezen voor een MySQL VPS, de add-on voor een site die al bij DreamHost wordt gehost. MySQL VPS is er in vier groottes, met 500 MB, 1 GB, 2 GB of 4 GB RAM volgens de pakketlijst in het panel van DreamHost. Om te zien welke grootte een database nodig heeft, hebben we databases van 460 MB, 1,8 GB en 4,6 GB gedraaid met het geheugen van elk pakket op een test-VM (geen server van DreamHost). Daarbij telden we hoeveel leesacties MySQL uit het geheugen beantwoordde. Een geaccepteerd antwoord op Server Fault zet de cache van MySQL op ongeveer 80% van het geheugen van de server. Onze resultaten hieronder laten zien waar dat misgaat op kleine servers. Draai je in plaats daarvan je eigen databaseserver op een VPS? Dan vertellen dezelfde cijfers je hoe groot je de pool moet instellen.

Je hele database hoeft niet in het RAM te passen. Matthew Boehm, die op het forum van Percona namens Percona antwoordt, vertelde een gebruiker die het vroeg dat een database van 4 TB kan draaien op 2 GB RAM bij ongeveer 100 alleen-lezen-query's per seconde. Heb je nog niet vastgesteld dat de database je pagina's vertraagt? Een trage plugin of een ontbrekende paginacache kan er van buitenaf hetzelfde uitzien. Begin dan met onze gids over uitzoeken of je database je site vertraagt.

Wat MySQL in de InnoDB-bufferpool bewaart

Het meeste gaat naar één cache. InnoDB, de engine die je tabellen opslaat, bewaart tabel- en indexgegevens in zijn buffer pool zodra het ze leest. Staan de gegevens die een query nodig heeft daar al, dan antwoordt MySQL vanuit het geheugen. Zo niet, dan gaat MySQL naar de schijf. Om ruimte te maken wordt iets ouders uit de cache verdrongen. De handleiding van MySQL waarschuwt dat een pool die te klein is steeds pagina's wegschrijft die hij een moment later weer nodig heeft.

De grootte ervan is een instelling: innodb_buffer_pool_size. De standaardwaarde van MySQL is 128 MB, op elke server. Met de automatische instelling voor een machine die alleen MySQL draait, houdt MySQL het bij 128 MB onder 1 GB geheugen en neemt het de helft van het geheugen bij 1 GB tot 4 GB. DreamHost publiceert niet welke cachegrootte elk pakket gebruikt, en een MySQL VPS heeft geen root- of SSH-toegang, dus je kunt de instelling niet zelf wijzigen.

De rest van het geheugen van MySQL krimpt niet mee met het abonnement. Op onze test-VM gebruikte MySQL 8.4 met de standaardinstellingen zo'n 470 MB voordat er ook maar één query draaide, met een cache van slechts 128 MB. De eigen telling van MySQL liet zien waar dat heen ging: naast de cache een logbuffer van 64 MB en ongeveer 150 MB voor het Performance Schema, de ingebouwde activiteitenmonitor van MySQL. Onder belasting, zodra de cache vol was, gebruikte het serverproces zo'n 450 tot 740 MB bovenop de cache. Op een server van 4 GB is dat een klein deel. Op 1 GB is het het grootste deel van het geheugen.

Wat we per pakket-RAM hebben gemeten

DreamHost voerde deze test uit op 19 oktober 2026 op een test-VM (arm64, 2 vCPU's), met een harde geheugenlimiet gelijk aan het RAM van elk abonnement. Het is geen server van DreamHost, dus lees de resultaten als wat het geheugen van elk abonnement aankan.

We beoordeelden elke meting op de hitrate: het aandeel leesacties dat MySQL uit de cache beantwoordde. Een database past als 99% of meer van de leesacties uit het geheugen komt en MySQL niet crasht. Tussen 95% en 99% is het krap. Onder 95% is het te klein. De grens van 95% komt van Boehm: bij 95% of hoger heb je volgens hem genoeg geheugen. De grens van 99% is onze eigen, strengere norm.

Bij de database van 1,8 GB betekent dat dat van elke 1.000 leesacties er ongeveer 35 naar de schijf gingen op 1 GB, 17 op 2 GB en 1 op 4 GB.

De grootte van de buffer pool deed er net zoveel toe als het RAM. Dit is de database van 1,8 GB op 2 GB geheugen bij elke poolgrootte die we probeerden:

Met de standaardwaarde van 128 MB bleef de hitrate rond 92 tot 96% bij elke limiet van 1 GB tot 4 GB. Een cache van ongeveer de helft van het RAM crashte nooit. Bij ongeveer driekwart crashte MySQL op 1 GB en 2 GB zodra de database groter was dan de cache, omdat het vaste deel daarbovenop nergens heen kon. Op 4 GB draaide driekwart prima. Op een server die je zelf beheert, is ongeveer de helft van het RAM dus een veilig startpunt voor innodb_buffer_pool_size bij 1 GB en 2 GB, en driekwart voor servers van 4 GB of meer, afgaand op onze enkele metingen.

Een limiet van 512 MB was te klein voor de standaardinstellingen van MySQL 8.4. MySQL gebruikte daarvan ongeveer 470 MB voordat er ook maar één query draaide, en elke test stopte zodra de limiet werd bereikt, zelfs met de database van 460 MB. VPS basic heeft 500 MB volgens de pakketlijst in het panel van DreamHost, en volgens de pagina van MySQL VPS is de server vooraf geconfigureerd. Een server die is ingesteld om minder geheugen te gebruiken, kan het beter doen dan onze server met standaardinstellingen. DreamHost publiceert de instellingen van VPS basic niet, dus vraag de support waarvoor dit pakket geschikt is voordat je er een drukke database op zet.

Waarom het actieve deel zwaarder weegt dan het totaal

In hetzelfde antwoord schat Boehm het actieve deel op ongeveer 10 tot 20% van het totaal en noemt hij dat gebruikelijk. Een webwinkel met drie jaar aan bestellingen leest de bestellingen van deze maand en de actuele producten veel vaker dan een factuur uit 2023. Onze testbelasting werkte net zo: die keerde steeds terug naar een drukke kern van rijen. Zo haalde een database van 4,6 GB 97,7% van de leesacties uit een cache van 2 GB.

Een rapport dat alle bestellingen sinds de lancering optelt, maakt al die rijen tegelijk druk. Dat slechtste scenario hebben we niet getest, dus we kunnen niet zeggen hoeveel lager de score zou uitvallen. Leunt je site op zoeken, rapporten of exports over oude gegevens? Zie de rijen in de tabel dan als het beste scenario en kies een abonnement hoger.

Controleer je eigen database voordat je kiest

Voor de eerste twee stappen heb je alleen het panel en phpMyAdmin nodig, en ze werken op het pakket dat je nu hebt.

1. Zoek uit op welke MySQL-server je zit

   Open de pagina MySQL Databases in je panel en lees de servernaam bovenaan. Het artikel in het Help Center van DreamHost over databaselogs bekijken legt de namen uit: een naam die begint met iad1 is gedeelde MySQL, en sql gevolgd door een nummer betekent dat je al op een eigen MySQL-server zit.

2. Meet hoe groot je databases zijn

   Voer deze query uit op het tabblad SQL van phpMyAdmin of via SSH. Hij komt uit het artikel in het Help Center van DreamHost over een database optimaliseren en toont per database de gegevens en indexen in MB.

   sqlKopiëren

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

3. Zoek de rij die bij je totaal past

   Tel alle databases op je account bij elkaar op, want volgens het Help Center van DreamHost worden ze allemaal verplaatst naar een nieuwe MySQL VPS. Zoek dat totaal op in de tabel hierboven. Valt het tussen twee rijen, kies dan het abonnement van de grotere rij. Zo houd je ruimte over voor groei. We hebben geen echte WordPress- of WooCommerce-databases gemeten, dus je eigen totaal is het getal om mee te werken.

4. Controleer de hitrate na de overstap

   Een MySQL VPS draait alleen je eigen databases, dus de tellers beschrijven alleen jouw databases. Lees Innodb_buffer_pool_read_requests en Innodb_buffer_pool_reads uit met SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; en bereken dan 1 min de schijfleesacties gedeeld door de leesverzoeken. SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; toont in bytes welke cachegrootte je abonnement heeft gekregen, zodat je die met de tabel kunt vergelijken. Op onze test-VM kon een gebruiker met rechten op één database beide uitlezen. Bij gedeelde MySQL gelden de tellers voor alle databases op die server. Daarom doe je deze controle pas na de verhuizing.

Wanneer je naar een groter pakket gaat

Stap over naar een groter pakket als de hitrate onder 95% zakt en daar blijft terwijl je data groeit. Volgens de pagina van MySQL VPS kun je je RAM opschalen vanuit het MySQL VPS-panel, en volgens het Help Center van DreamHost wordt het ongebruikte deel van het oude pakket verrekend met het nieuwe.

Betaal niet voor geheugen voordat je naar je traagste query's hebt gekeken. Verderop in dezelfde discussie op het forum van Percona liet het tuningrapport van een gebruiker een hitrate van 100% zien naast miljoenen joins zonder index. Het antwoord van Boehm was kort: No amount of ram will fix a bad query. Onze gids over trage MySQL-query's vinden laat zien hoe je ze opspoort met Query Monitor en EXPLAIN. Wil je een MySQL-server tunen die je zelf beheert? Lees dan ons artikel over databaseprestaties verbeteren op een VPS.

Meer dan 4 GB aan actieve data

Groeit het drukke deel van je gegevens boven de 4 GB van VPS enterprise uit, dan heeft DreamHost twee grotere opties. Een dedicated server heeft 16 GB RAM of meer en draait MySQL op dezelfde machine als je site. Volgens het MySQL-overzicht in het Help Center van DreamHost past dat bij software die grote hoeveelheden gegevens tussen de app en MySQL uitwisselt, en volgens de pagina van MySQL VPS krijg je daar toegang tot de configuratiebestanden van MySQL. Draai je liever je eigen databaseserver? Een VPS gaat tot 32 GB RAM met Stack 32, waarop je MySQL zelf installeert en de buffer pool zelf instelt.

Overweeg je in plaats daarvan een clouddatabase? Onze gids over de prijzen van RDS for MySQL naast een privé-MySQL-server zet de kosten van beide op een rij.

Hoe we hebben gemeten

DreamHost voerde de test uit op 19 oktober 2026, op Ubuntu 24.04.4 onder Colima op een Mac met Apple silicon: arm64, 2 vCPU's en geen swap. MySQL 8.4.11 draaide vanuit de officiële Docker-image met de standaardinstellingen, behalve de geteste cachegrootte en twee opties die we uitschakelden (de cache bewaren tussen herstarts, en de binaire log). Een geheugenlimiet in Docker van 512 MB, 1 GB, 2 GB of 4 GB stond voor elk abonnement. Elke database bestond uit tabellen van sysbench, met elk 1 miljoen rijen. sysbench 1.0.20 genereerde een gemengde lees- en schrijfbelasting die een drukke kern van rijen bevoordeelt, met 8 threads op een constante 360 transacties per seconde. Elke meting had een opwarmtijd van 2 minuten (5 voor de database van 4,6 GB) en een meetvenster van 3 minuten. Elke cache werd getest op 128 MB, ongeveer de helft en ongeveer driekwart van het geheugen.

De test heeft beperkingen. Een MySQL VPS draait in een eigen Linux-container op de hardware van DreamHost, en DreamHost publiceert de cachegrootte, de verbindingslimiet en de swap per abonnement niet. Je ziet op een MySQL VPS dus niet precies dezelfde cijfers. Elke instelling is één keer gemeten, dus we kunnen niet laten zien hoeveel een herhaalde meting zou afwijken, en kleine verschillen kunnen ruis zijn. We hebben het slechtste scenario waarin elke rij even druk is niet getest, het geheugen per verbinding niet gemeten, geen echte WordPress- of WooCommerce-databases gemeten en MySQL 8.0 niet getest.

Veelgestelde vragen over MySQL-geheugen