Wie viel RAM braucht MySQL, und wie groß sollte der Buffer Pool sein?

Dieser Leitfaden hilft dir, die passende Größe für einen MySQL VPS zu wählen, das Add-on für eine Website, die bereits bei DreamHost gehostet wird. MySQL VPS gibt es laut der Tarifliste im DreamHost-Panel in vier Größen mit 500 MB, 1 GB, 2 GB oder 4 GB RAM. Um herauszufinden, welche Größe eine Datenbank braucht, haben wir Datenbanken mit 460 MB, 1,8 GB und 4,6 GB auf einer Test-VM (keinem Server von DreamHost) mit dem Arbeitsspeicher jedes Tarifs betrieben. Dabei haben wir gezählt, wie viele Lesezugriffe MySQL aus dem Speicher beantwortet hat. Eine akzeptierte Antwort auf Server Fault setzt den Cache von MySQL auf etwa 80 % des Arbeitsspeichers des Servers. Unsere Ergebnisse unten zeigen, wo das auf kleinen Servern schiefgeht. Wenn du stattdessen deinen eigenen Datenbankserver auf einem VPS betreibst, zeigen dir dieselben Zahlen, wie groß du den Pool einstellen solltest.

Die gesamte Datenbank muss nicht in den RAM passen. Matthew Boehm, der im Forum von Percona für das Unternehmen antwortet, schrieb einem Nutzer auf dessen Frage, dass eine 4-TB-Datenbank mit 2 GB RAM bei etwa 100 reinen Lese-Abfragen pro Sekunde laufen kann. Falls du noch nicht bestätigt hast, dass wirklich die Datenbank deine Seiten ausbremst – ein langsames Plugin oder ein fehlender Seiten-Cache kann von außen genauso aussehen –, fang mit unserem Leitfaden an, wie du herausfindest, ob deine Datenbank deine Website verlangsamt.

Was MySQL im InnoDB-Buffer-Pool speichert

Der Großteil geht an einen einzigen Cache. InnoDB, die Engine, die deine Tabellen speichert, legt Tabellen- und Indexdaten in ihrem Buffer Pool ab, sobald sie sie liest. Wenn die Daten, die eine Abfrage braucht, schon dort liegen, antwortet MySQL aus dem Arbeitsspeicher. Wenn nicht, greift MySQL auf die Festplatte zu. Dafür wird etwas Älteres verdrängt, um Platz zu schaffen. Das Handbuch von MySQL warnt, dass ein zu kleiner Pool ständig Seiten auslagert, die er einen Moment später wieder braucht.

Seine Größe legt eine Einstellung fest: innodb_buffer_pool_size. Der Standardwert von MySQL beträgt auf jedem Server 128 MB. Mit seiner automatischen Einstellung für einen Rechner, auf dem nur MySQL läuft, belässt MySQL den Cache bei weniger als 1 GB Arbeitsspeicher bei 128 MB und nimmt sich von 1 GB bis 4 GB die Hälfte des Arbeitsspeichers. DreamHost veröffentlicht nicht, welche Cache-Größe die einzelnen Tarife nutzen, und ein MySQL VPS bietet keinen Root- oder SSH-Zugriff. Du kannst die Einstellung also nicht selbst ändern.

Der restliche Arbeitsspeicher von MySQL schrumpft nicht mit dem Tarif. Auf unserer Test-VM belegte MySQL 8.4 mit Standardeinstellungen schon vor der ersten Abfrage etwa 470 MB, bei nur 128 MB Cache. Die eigene Zählung von MySQL zeigte, wohin der Speicher ging: neben dem Cache ein Log-Puffer von 64 MB und etwa 150 MB für das Performance Schema, den integrierten Aktivitäts-Tracker von MySQL. Unter Last, sobald der Cache gefüllt war, lag der Serverprozess etwa 450 bis 740 MB darüber. Auf einem 4-GB-Server ist das ein kleiner Anteil. Bei 1 GB ist es der Großteil des Arbeitsspeichers.

Was wir beim RAM jedes Plans gemessen haben

DreamHost hat diesen Test am 19. Oktober 2026 auf einer Test-VM (arm64, 2 vCPU) durchgeführt, mit einem festen Speicherlimit in Höhe des RAM jedes Tarifs. Es handelt sich nicht um einen DreamHost-Server, lies die Ergebnisse also als das, was der Arbeitsspeicher jedes Tarifs fassen kann.

Wir haben jeden Durchlauf anhand seiner Trefferquote bewertet, also des Anteils der Lesezugriffe, die MySQL aus seinem Cache beantwortet hat. Eine Datenbank passt, wenn 99 % oder mehr ihrer Lesezugriffe aus dem Arbeitsspeicher kommen und MySQL nicht abstürzt. Zwischen 95 % und 99 % ist es knapp. Unter 95 % ist der Speicher zu klein. Die 95-%-Grenze stammt von Boehm: Ab 95 %, sagt er, hast du genug Arbeitsspeicher. Die 99-%-Grenze ist unsere eigene, strengere Marke.

Bei der 1,8-GB-Datenbank heißt das: Von je 1.000 Lesezugriffen gingen bei 1 GB etwa 35 auf die Festplatte, bei 2 GB 17 und bei 4 GB 1.

Die Größe des Buffer Pools war genauso wichtig wie der RAM. So lief die 1,8-GB-Datenbank mit 2 GB Arbeitsspeicher bei jeder getesteten Pool-Größe:

Mit dem Standardwert von 128 MB lagen die Trefferquoten bei jedem Limit von 1 GB bis 4 GB bei etwa 92 bis 96 %. Mit einem Cache von etwa der Hälfte des RAM stürzte MySQL nie ab. Mit etwa drei Vierteln stürzte MySQL bei 1 GB und 2 GB ab, sobald die Datenbank größer als der Cache war, weil der feste Anteil darüber keinen Platz mehr hatte. Bei 4 GB liefen drei Viertel problemlos. Auf einem Server, den du selbst betreibst, ist bei 1 GB und 2 GB also etwa die Hälfte des RAM der sichere Ausgangswert für innodb_buffer_pool_size, drei Viertel kommen erst ab 4 GB infrage – gemessen an unseren einzelnen Durchläufen.

Ein Limit von 512 MB war für die Standardeinstellungen von MySQL 8.4 zu klein. MySQL belegte davon schon vor der ersten Abfrage etwa 470 MB, und jeder Durchlauf brach ab, sobald er das Limit erreichte, selbst mit der 460-MB-Datenbank. VPS basic hat laut der Tarifliste im DreamHost-Panel 500 MB, und laut der Seite zu MySQL VPS ist der Server vorkonfiguriert. Ein Server, der auf weniger Arbeitsspeicher ausgelegt ist, könnte besser abschneiden als unserer mit Standardeinstellungen. DreamHost veröffentlicht die Einstellungen von VPS basic nicht. Frag deshalb den Support, wofür sich der Tarif eignet, bevor du eine stark genutzte Datenbank darauf legst.

Warum der aktive Teil wichtiger ist als die Gesamtgröße

In derselben Antwort beziffert Boehm den aktiven Teil auf etwa 10 bis 20 % der Gesamtgröße und nennt das typisch. Ein Shop mit drei Jahren Bestellungen liest die Bestellungen dieses Monats und seine aktuellen Produkte viel öfter als eine Rechnung von 2023. Unsere Testlast funktionierte genauso: Sie kehrte immer wieder zu einem stark genutzten Kern von Zeilen zurück. So kamen bei einer 4,6-GB-Datenbank 97,7 % der Lesezugriffe aus einem 2-GB-Cache.

Ein Bericht, der alle Bestellungen seit dem Start summiert, macht all diese Zeilen auf einmal aktiv. Diesen Extremfall haben wir nicht getestet, daher können wir nicht sagen, wie viel schlechter er abschneiden würde. Wenn deine Website stark auf Suche, Berichte oder Exporte über alte Daten setzt, betrachte die Werte der Tabelle als besten Fall und wähle einen Tarif größer.

Prüfe deine eigene Datenbank, bevor du wählst

Für die ersten beiden Schritte brauchst du nur das Panel und phpMyAdmin, und beide funktionieren mit deinem aktuellen Tarif.

1. Finde heraus, auf welchem MySQL-Server du bist

   Öffne in deinem Panel die Seite MySQL Databases und lies oben den Servernamen ab. Der Artikel im Help Center von DreamHost zum Anzeigen von Datenbank-Logs erklärt die Namen: Ein Name, der mit iad1 beginnt, steht für gemeinsam genutztes MySQL, und sql gefolgt von einer Zahl bedeutet, dass du bereits auf einem privaten MySQL-Server bist.

2. Miss, wie groß deine Datenbanken sind

   Führe diese Abfrage im SQL-Tab von phpMyAdmin oder per SSH aus. Sie stammt aus dem Artikel im Help Center von DreamHost zum Optimieren einer Datenbank und zeigt die Daten und Indizes jeder Datenbank in MB.

   sqlKopieren

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

3. Ordne die Gesamtgröße einer Zeile zu

   Zähle alle Datenbanken in deinem Account zusammen, denn laut Help Center von DreamHost werden alle auf den neuen MySQL VPS umgezogen. Such diese Summe in der Tabelle oben. Liegt sie zwischen zwei Zeilen, nimm den Tarif der größeren Zeile. So bleibt Platz, damit die Daten wachsen können. Wir haben keine echten WordPress- oder WooCommerce-Datenbanken gemessen, deshalb ist deine eigene Summe der Wert, auf den es ankommt.

4. Prüfe die Trefferquote nach dem Umzug

   Auf einem MySQL VPS laufen nur deine Datenbanken, seine Zähler beschreiben also ausschließlich deine Datenbanken. Lies Innodb_buffer_pool_read_requests und Innodb_buffer_pool_reads mit SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; aus und rechne dann 1 minus Lesevorgänge geteilt durch Leseanfragen. SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; zeigt die Cache-Größe deines Tarifs in Bytes, damit du sie mit der Tabelle vergleichen kannst. Auf unserer Test-VM konnte ein Nutzer mit Rechten für eine einzige Datenbank beide Werte lesen. Auf Shared MySQL decken die Zähler alle Datenbanken auf diesem Server ab, deshalb kommt diese Prüfung erst nach dem Umzug.

Wann du auf einen größeren Plan wechseln solltest

Wechsle auf einen größeren Tarif, wenn die Trefferquote unter 95 % fällt und dort bleibt, während deine Daten wachsen. Laut der Seite zu MySQL VPS kannst du deinen RAM im Panel für MySQL VPS aufstocken, und laut Help Center von DreamHost wird der ungenutzte Teil des alten Tarifs auf den neuen angerechnet.

Bezahl nicht für Arbeitsspeicher, bevor du dir deine langsamsten Abfragen angesehen hast. Später im selben Percona-Thread zeigte der Tuning-Bericht eines Nutzers eine Trefferquote von 100 % neben Millionen von Joins ohne Index, und Boehm antwortete knapp: No amount of ram will fix a bad query. Unser Leitfaden zum Finden langsamer MySQL-Abfragen zeigt, wie du sie mit Query Monitor und EXPLAIN aufspürst. Wie du einen selbst betriebenen MySQL-Server optimierst, erfährst du in unserem Beitrag zur Verbesserung der Datenbank-Performance auf einem VPS.

Mehr als 4 GB aktive Daten

Wenn der aktive Teil deiner Daten die 4 GB von VPS enterprise übersteigt, bietet DreamHost zwei größere Lösungen. Ein dedizierter Server hat 16 GB RAM oder mehr und betreibt MySQL auf demselben Rechner wie deine Website. Laut der MySQL-Übersicht im Help Center von DreamHost eignet sich das für Software, die große Datenmengen zwischen App und MySQL bewegt, und laut der MySQL-VPS-Seite hast du dort Zugriff auf die Konfigurationsdateien von MySQL. Wenn du lieber deinen eigenen Datenbankserver betreibst, bietet ein VPS mit Stack 32 bis zu 32 GB RAM. Dort installierst du MySQL und stellst den Buffer Pool selbst ein.

Wenn du stattdessen eine Cloud-Datenbank in Betracht ziehst, findest du in unserem Leitfaden RDS for MySQL im Preisvergleich mit einem privaten MySQL-Server die Kosten beider Optionen.

Wie wir gemessen haben

DreamHost hat den Test am 19. Oktober 2026 unter Ubuntu 24.04.4 mit Colima auf einem Mac mit Apple Silicon durchgeführt: arm64, 2 vCPU und kein Swap. MySQL 8.4.11 lief aus dem offiziellen Docker-Image mit Standardeinstellungen, abgesehen von der jeweils getesteten Cache-Größe und zwei deaktivierten Optionen (dem Speichern des Caches zwischen Neustarts und dem Binärlog). Ein Docker-Speicherlimit von 512 MB, 1 GB, 2 GB oder 4 GB stand jeweils für einen Tarif. Jede Datenbank bestand aus sysbench-Tabellen mit je 1 Million Zeilen. sysbench 1.0.20 erzeugte eine gemischte Lese- und Schreiblast, die einen stark genutzten Kern von Zeilen bevorzugt, mit 8 Threads bei konstant 360 Transaktionen pro Sekunde. Jeder Durchlauf hatte eine Aufwärmphase von 2 Minuten (5 bei der 4,6-GB-Datenbank) und ein Messfenster von 3 Minuten. Jeder Cache wurde mit 128 MB, etwa der Hälfte und etwa drei Vierteln des Arbeitsspeichers getestet.

Der Test hat Grenzen. Ein MySQL VPS läuft in einem eigenen Linux-Container auf der Hardware von DreamHost, und Cache-Größe, Verbindungslimit und Swap der einzelnen Tarife veröffentlicht DreamHost nicht. Du wirst auf einem MySQL VPS also nicht exakt dieselben Zahlen sehen. Jede Einstellung lief nur einmal, daher können wir nicht zeigen, wie stark ein wiederholter Durchlauf abweichen würde, und kleine Unterschiede können Zufall sein. Wir haben weder den Extremfall getestet, in dem jede Zeile gleich stark genutzt wird, noch den Arbeitsspeicher pro Verbindung gemessen, echte WordPress- oder WooCommerce-Datenbanken dimensioniert oder MySQL 8.0 getestet.

FAQ zum Arbeitsspeicher von MySQL