Meine Datenbank bremst meine Website aus. Braucht sie einen eigenen Server?

Dein Shop lädt frühmorgens problemlos und wird zur Mittagszeit zäh. Das WordPress-Dashboard braucht ein paar Sekunden, um ein Produkt zu öffnen. Ein Speedtest gibt dir eine ordentliche Punktzahl und einen vagen Hinweis zur Server-Antwortzeit. Jemand in einem Forum sagt, die Datenbank sei das Problem, und jemand anderes meint, ein größerer Server löse es.

DreamHost selbst weist in seinem Leitfaden zu WordPress-Datenbanken darauf hin, dass Online-Speedtools deine Datenbank nicht erreichen. Eine Website kann also gut abschneiden und trotzdem langsame Abfragen ausführen. Du brauchst einen Test, der in die Seite schaut, während sie aufgebaut wird. Genau das macht Query Monitor.

Wir gehen der Reihe nach vor. Finde zuerst heraus, ob MySQL der langsame Teil ist. Behebe dann, was du auf deinem aktuellen Server beheben kannst. Entscheide zum Schluss, ob sich ein privater MySQL-Server lohnt und was sich ändert, wenn deine Daten umziehen.

Prüfen, ob die Datenbank bremst

Alle folgenden Prüfungen kannst du in deinem Panel und in WordPress durchführen, ohne Admin-Rechte auf dem MySQL-Server zu haben. Keine davon verändert deine Website, abgesehen von der Installation eines Plugins.

1. Deinen MySQL-Server und seinen Standort ermitteln

   Öffne in deinem Panel die Seite MySQL Databases und lies den Servernamen neben jeder Datenbank ab. Die Anleitung von DreamHost zu Datenbank-Logs erklärt die Namen: Ein Name, der mit iad1 beginnt, steht für einen Shared-MySQL-Server, sql gefolgt von einer Zahl für einen privaten MySQL-Server und ds für einen dedizierten Server. Beginnt deiner bereits mit sql, bist du schon auf einem privaten Server, und die Kaufsignale weiter unten treffen auf dich nicht zu. Öffne dann im Panel die Seite Data Centers. Dein Web- und dein MySQL-Server sollten im selben Rechenzentrum stehen, damit die Netzwerkverzögerung gering bleibt. Ist das nicht der Fall, kann der Support sie verschieben.

2. Query Monitor installieren und zwei Werte vergleichen

   Query Monitor ist ein kostenloses Plugin, das alle Datenbankabfragen einer Seite auflistet und nach Plugin, Theme oder WordPress-Core gruppiert. Melde dich als Administrator an und öffne eine Seite, die sich langsam anfühlt. Das Menü des Plugins in der Admin-Toolbar zeigt die Seitengenerierungszeit und die Gesamtzeit der SQL-Abfragen, beide in Sekunden. Vergleiche die beiden Werte. Macht die Abfragezeit nur einen kleinen Teil der Generierungszeit aus, bremst etwas anderes als die Datenbank die Seite, etwa HTTP-Aufrufe oder das Rendern von Blöcken.

3. Plugin und Abfragen finden, die die Zeit kosten

   Öffne den Bereich Queries by Component. Er ist nach Gesamtzeit sortiert, sodass das Plugin oder Theme mit der meisten Datenbankzeit ganz oben steht. Der Autor des Plugins nennt ihn den richtigen Ausgangspunkt, wenn sich eine Website langsam anfühlt. Query Monitor markiert eine Abfrage als langsam, sobald sie 0,05 Sekunden überschreitet. Außerdem kennzeichnet es Duplikate. Sie bedeuten meist, dass Code eine Abfrage in einer Schleife ausführt, obwohl er einmal abfragen und das Ergebnis cachen könnte.

4. Dieselbe Seite zu einer ruhigen und einer belebten Stunde laden

   Query Monitor speichert keinen Verlauf, also schreib dir die Werte auf. Lade die langsame Seite zu einer ruhigen Zeit und dann noch einmal zu deiner stärksten Stunde. Vergleiche die gesamte Abfragezeit und die Zeiten derselben langsamen Abfragen. Der Beitrag von DreamHost zum Thema Datenbank-Performance verbessern nennt Verlangsamungen bei Spitzenlast als eines der Anzeichen dafür, dass die Datenbank der Engpass ist. Er empfiehlt außerdem, die Auslastung deines Servers zu Spitzenzeiten zu prüfen.

5. Die Nutzungsgrafik für dieselben Stunden lesen

   Bei Webhosting stellt die Seite Servers & Usage CPU, RAM und Speicher als Low, Medium oder High dar, und zwar für den letzten Tag, die letzte Woche oder die letzten zwei Wochen. Laut dem Nutzungsleitfaden im Help Center teilen sich mehrere Konten CPU und RAM auf dem Webserver, die Diagramme zeigen aber nur die Nutzung deines Kontos. Ein High-Wert deutet auf dein eigenes PHP und deine Plugins hin. Ein normaler Wert sagt dir, dass dein Konto nicht der große Verbraucher ist. Wie ausgelastet der Rest des Servers ist, verrät er dir aber nicht.

Ordne jetzt deine Beobachtung einer wahrscheinlichen Ursache zu:

Was dir Shared MySQL nicht zeigt

Bei Shared MySQL siehst du die Logs des Servers nicht, auch nicht die Slow Query Logs. Laut dem Leitfaden zu Datenbank-Logs von DreamHost kann der Support sie dir ebenfalls nicht beschaffen. Deinem MySQL-Benutzer fehlt außerdem das PROCESS-Privileg. Eine Prozessliste zeigt deshalb nur deine eigenen Abfragen, und SET GLOBAL zum Ändern von Servereinstellungen kann dein Benutzer nicht ausführen.

Das Slow Query Log, über das du im MySQL-Handbuch liest, ist hier also außer Reichweite. Es ist standardmäßig deaktiviert, und nur jemand mit Admin-Rechten auf dem Server kann es einschalten. Sein Standardlimit liegt bei 10 Sekunden. Laut demselben Leitfaden im Help Center kann der Support von DreamHost auf Anfrage Logs von einem privaten MySQL-Server für dich abrufen. Auf einem dedizierten Server bekommst du die MySQL-Konfigurationsdateien selbst.

Zuerst dort beheben, wo das Problem entsteht

Das alles funktioniert mit deinem aktuellen Tarif, bevor du für irgendetwas bezahlst.

Sieh dir die langsamen Abfragen mit EXPLAIN an. Kopiere eine langsame Abfrage aus Query Monitor. Setze EXPLAIN davor und führe sie in phpMyAdmin aus. Die Dokumentation zur EXPLAIN-Anweisung von MySQL beschreibt, wie sie den Plan anzeigt, den MySQL verwenden wird, einschließlich der Indizes, die MySQL liest. EXPLAIN ANALYZE führt die Abfrage aus und meldet die tatsächliche Laufzeit. Shared MySQL bei DreamHost gewährt das INDEX-Privileg. Du kannst also einen Index hinzufügen, wenn der Plan zeigt, dass MySQL eine ganze Tabelle durchsucht. Notiere dir jeden Index, den du einer WordPress- oder WooCommerce-Tabelle hinzufügst, damit du nach Updates prüfen kannst, ob er noch da ist.

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

Räume die eigenen Tabellen von WordPress auf. Die Schritte zur Bereinigung von WordPress-Datenbanken von DreamHost laufen per SSH mit WP-CLI. Sie löschen Transients, optimieren die Tabellen, kürzen Beitragsrevisionen und bereinigen die Tabellen postmeta und commentmeta. Prüfe vor allem anderen deine Autoload-Größe, denn WordPress lädt diese Optionen bei jeder Anfrage. Unter etwa 600 KB ist für die meisten Server gut. Diese Befehle stammen aus dem 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 mit viel Overhead verlangsamen Abfragen. Im schlimmsten Fall läuft der Webserver in ein Timeout, während er auf eine Antwort wartet. Die Option Optimize table in phpMyAdmin entfernt den Overhead, wie der Leitfaden zu Performance-Problemen von DreamHost erklärt.

Aktiviere Caching. Die Performance-Dokumentation von WordPress selbst nennt Caching den schnellsten Weg zu besserer Performance. Ein Page-Cache-Plugin liefert Beiträge und Seiten als statische Dateien aus, sodass die meisten Besuche MySQL nie erreichen. Füge dann einen Objekt-Cache hinzu.

Für Shared Hosting dokumentiert das Help Center von DreamHost das Plugin Docket Cache als dateibasierten persistenten Objekt-Cache. OPcache, das dafür nötig ist, ist bereits aktiv. Wenn du dich gar nicht um Caching kümmern willst, erledigt das WordPress-Hosting mit integriertem Caching von DreamHost das direkt auf dem Server.

Einstellungen auf Serverebene wie der InnoDB-Speicher sind ein eigenes Thema. Wir behandeln sie in unserem Beitrag zum Tuning von MySQL auf einem VPS.

Anzeichen, dass die Datenbank einen eigenen Server braucht

DreamHost beschreibt Shared MySQL als geeignet für optimierte Datenbanken und normale Website-Performance. MySQL VPS ist laut DreamHost für Kunden gedacht, die schnellere Datenbankantworten brauchen oder Shared MySQL entwachsen sind. Die Seite zu MySQL VPS nennt in ihren FAQ auch die Grenze des Teilens: „Ein geteilter Server kann bei ungewöhnlich hohem Traffic zu Performance-Engpässen führen.“

Langsame Abfragen allein bedeuten nicht, dass Shared MySQL das falsche Zuhause ist. Zieh einen privaten Server erst in Betracht, wenn du die Korrekturen oben umgesetzt hast und diese Anzeichen trotzdem weiter auftreten:

• Dieselben Abfragen laufen zu deiner stärksten Stunde langsamer. Deine Notizen aus Query Monitor zu ruhigen und stark besuchten Zeiten zeigen, dass dieselben Abfragen bei hohem Traffic deutlich länger dauern, auch nach Aufräumen und Caching.
• Verbindungsfehler treten immer wieder auf, obwohl du den Hostnamen geprüft und der Support den Server untersucht hat. Ein MySQL VPS gibt deinen Datenbanken Ressourcen, die sie nicht mit anderen Nutzern teilen. DreamHost veröffentlicht für keine der beiden Serverarten Verbindungslimits, deshalb können wir dir keine Zahl nennen.
• Deine App braucht Trigger oder gespeicherte Routinen. Laut Help Center von DreamHost kannst du auf Shared MySQL keine neuen Trigger anlegen, und gespeicherte Routinen sind dort als nicht verfügbar aufgeführt. Ein MySQL VPS unterstützt beides.
• Du brauchst MySQL-Logs zum Debuggen. Laut Help Center von DreamHost kann der Support sie von einem privaten MySQL-Server abrufen.

Wenn nichts davon zutrifft, bleib, wo du bist. Eine Antwort auf Stack Overflow von 2009 spricht fürs Bleiben:

Die Top-Antwort im selben Thread mit 188 Stimmen argumentiert aus Gründen der Skalierung und Performance in die andere Richtung. Entscheide anhand deiner eigenen Werte zur stärksten Stunde.

Was sich beim Umzug der Datenbank ändert

Falls du befürchtest, dass eine entfernte Datenbank einen zusätzlichen Netzwerk-Hop bedeutet: Deine Website hat bereits einen. Die MySQL-Übersicht von DreamHost zeigt, wo jede Art von MySQL-Server läuft:

Deshalb rät das Help Center von DreamHost Kunden, niemals localhost als Datenbank-Host zu verwenden. Ein MySQL VPS ändert nur, wo die Datenbank liegt, und deine Website erreicht sie weiterhin über das Netzwerk. Die Forengeschichten über entfernte Datenbanken stammen aus anderen Setups. In einem Thread auf Server Fault nutzte eine Website in den USA eine Datenbank in Asien. Sie reagierte sehr langsam, bis die Datenbank auf einen lokalen Server umzog. Die Entfernung verursachte diese Verzögerung. Deshalb steht die Prüfung des Rechenzentrums in den Schritten oben an erster Stelle.

Der Umzug selbst läuft über das Panel:

1. Alle Datenbanken sichern
   Exportiere zuerst eine Kopie jeder Datenbank.
2. Einen MySQL VPS im Panel hinzufügen

   Wenn du bereits ein VPS in deinem Konto hast, nutze Add Service+ auf der Seite Servers & Usage. Falls nicht, öffne die Seite MySQL Databases und klicke auf Turn on a MySQL VPS!. Die Anleitung von DreamHost zum Hinzufügen eines MySQL VPS deckt beide Wege ab. Die Bereitstellung kann ein paar Stunden dauern.

3. Eine ruhige Nacht für den Umzug wählen

   Laut Help Center verschiebt DreamHost alle Datenbanken in deinem Konto um Mitternacht pazifischer Zeit auf den neuen Server, und das Panel zeigt das als Zusammenführung an. Dort steht nicht, ob deine Website während des Umzugs ausfällt oder wie lange der Umzug dauert. Füge den Server an einem Tag hinzu, an dem Mitternacht pazifischer Zeit für deine Besucher eine ruhige Stunde ist, und frag vorher beim Support nach, wenn du eine verbindliche Antwort brauchst.

4. Nach Nachzüglern suchen

   Manche Datenbanken landen teils auf dem alten Shared-Server und teils auf dem neuen. Mit dem Button Move my databases! auf der Seite MySQL Databases führst du sie wieder an einem Ort zusammen.

5. Hostname abgleichen und erneut testen

   Öffne die Seite MySQL Databases und vergleiche den Hostnamen, der dort für jede Datenbank angezeigt wird, mit DB_HOST in deiner Konfigurationsdatei. Weichen sie voneinander ab, ändere DB_HOST so, dass es zum Panel passt. Ein neu hinzugefügter Hostname kann bis zu 4 Stunden brauchen, bis er funktioniert, weil Datenbank-Hostnamen DNS-Namen sind. Lade dann deine langsamen Seiten zu denselben ruhigen und stark besuchten Stunden und vergleiche die Zeiten mit deinen Notizen.

Nach dem Umzug funktionieren einige Dinge anders:

• Root- oder SSH-Zugriff bekommst du trotzdem nicht. MySQL VPS ist verwaltet: DreamHost übernimmt Wartung, Sicherheitspatches und OS-Updates für dich, und die MySQL-Einstellungen legt weiterhin DreamHost fest. Wenn du die Konfigurationsdateien brauchst oder deine App große Datenmengen mit MySQL austauscht, verweist DreamHost dich auf einen dedizierten Server, auf dem MySQL auf derselben Maschine läuft.
• RAM lässt sich später erweitern. Du kannst den RAM jederzeit im Panel erhöhen, und laut Help Center erhältst du eine anteilige Gutschrift für den alten Tarif.
• Du kannst prüfen, ob deine Daten in den Speicher passen. Führe SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; aus und berechne 1 minus Innodb_buffer_pool_reads geteilt durch Innodb_buffer_pool_read_requests. Auf einem Server, auf dem nur deine Datenbanken laufen, ergibt das den Anteil der Lesezugriffe, die aus dem Speicher bedient werden – also den Wert in der Größentabelle unten. Auf unserem Test-MySQL konnte ein Benutzer mit Rechten für eine einzige Datenbank diese Zähler lesen, SHOW ENGINE INNODB STATUS aber nicht.
• Der Weg zurück hat eine Größengrenze. Wenn du keinen dedizierten Server hast, muss jede Datenbank auf dem MySQL VPS kleiner als 3 GB sein, bevor du den Server im Panel löschen kannst. Danach wählst du einen Zielserver, und DreamHost verschiebt deine Daten innerhalb von 24 Stunden auf den geteilten Datenbankserver.

Welche Option passt

Wähle den Weg, der zu den Ergebnissen deiner Prüfungen passt.

Für den Weg mit MySQL VPS startest du mit VPS business. Die Seite von DreamHost kennzeichnet ihn mit Built for Small Business, und laut Tarifliste im DreamHost-Panel hat er 1 GB RAM und 20 GB Speicherplatz. VPS basic ist die Stufe darunter. Die Seite beschreibt VPS basic als For new & small websites. Das passt zu einer kleinen Website, die vor allem wegen Triggern, Routinen oder Logs umziehen will. VPS basic hat laut der Tarifliste von DreamHost 500 MB RAM. In unserem Test brach MySQL mit Standardeinstellungen unter Last bei einem Limit von 512 MB ab, selbst mit einer kleinen Datenbank. DreamHost richtet MySQL für jeden Tarif selbst ein und veröffentlicht die Einstellungen von VPS basic nicht. Frag also den Support, wofür sich der Tarif eignet, bevor du eine stark genutzte Datenbank dorthin verschiebst.

Bevor du dich entscheidest, schau nach, wie groß deine Datenbanken sind. Die Anleitung von DreamHost zum Optimieren einer Datenbank nennt dafür diese Abfrage. Verbinde dich per SSH mit der Datenbank und führe sie aus, um die Daten und Indizes jeder Datenbank in MB zu sehen:

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

Liegt die Gesamtgröße deutlich über dem RAM des Tarifs, kann MySQL nicht alles im Speicher halten. Starte dann eine Stufe größer.

Wie viele Daten 1 GB auf unserer Test-VM aufnahm

Wir haben diese Regel getestet, bevor wir uns darauf verlassen. Auf einer Test-VM haben wir MySQL 8.4 ein festes Speicherlimit in der Größe jedes MySQL-VPS-Tarifs gegeben, den Cache auf etwa die Hälfte davon gesetzt und eine gleichmäßige, webähnliche Last auf drei Datenbankgrößen laufen lassen. Die Tabelle zeigt, wie viele Lesezugriffe MySQL aus dem Speicher beantwortet hat und wie lange die langsamsten 5 % der Transaktionen gedauert haben. Jede Transaktion ist ein Bündel aus Lese- und Schreibzugriffen, ähnlich wie ein Seitenaufruf.

Eine Datenbank unter der Hälfte des Tarif-RAM blieb schnell. Sobald die Daten größer als der RAM waren, wurden die langsamsten Transaktionen langsamer: 18,6 ms für die 1,8-GB-Datenbank mit 1 GB, gegenüber 8,7 ms eine Tarifstufe höher. Bei 4,6 GB mit 1 GB kam MySQL mit der Last überhaupt nicht mehr mit. Ein Limit von 512 MB, nah an den 500 MB von VPS basic, war für MySQL mit Standardeinstellungen zu klein: Es belegte schon vor der ersten Abfrage rund 470 MB, und jeder Durchlauf stieß an das Limit.

Das sind unsere Testeinstellungen, nicht die von DreamHost. DreamHost richtet MySQL für jeden Tarif ein und veröffentlicht die Cache-Größe nicht, und auf einem MySQL VPS kannst du die Servereinstellungen von MySQL nicht ändern. Nimm die Tabelle als Orientierung dafür, wie viele Daten jede Speichergröße bequem fasst. Den vollständigen Test mit allen getesteten Cache-Größen findest du in unserem Leitfaden dazu, wie viel RAM MySQL braucht.

Wir können dir nicht sagen, wie viele Besucher jeder Tarif verkraftet, denn das hängt stärker von deinen Abfragen ab als von deiner Größe. Wenn deine Zeiten zur Hauptbesuchszeit mit wachsenden Daten wieder ansteigen, erhöhe den RAM im Panel.

Wie wir die Speicherfrage getestet haben

Die Speicherwerte hat DreamHost auf einer Test-VM (arm64) gemessen, nicht auf einem Server von DreamHost. Ein festes Speicherlimit stand jeweils für den RAM eines MySQL-VPS-Tarifs. Den Durchlauf haben wir am 19. Oktober 2026 für unseren Leitfaden zur RAM-Größe gemacht, und diese Seite nutzt ihn erneut. Die VM lief mit Ubuntu 24.04 unter Colima auf einem Mac, mit 2 vCPU und ohne Swap. MySQL 8.4.11 lief aus dem offiziellen Docker-Image mit Standardeinstellungen, abgesehen von der Cache-Größe. sysbench erzeugte eine gemischte Lese- und Schreiblast mit Schwerpunkt auf einem viel genutzten Kern von Zeilen: 8 Threads bei konstant 360 Transaktionen pro Sekunde, mit einem gemessenen Zeitfenster von 3 Minuten nach einer Aufwärmphase.

Die Seite zum MySQL VPS nennt MySQL 8.0, und laut dem Help-Center-Artikel Using reserved words in MySQL 8 von DreamHost kannst du auf einem VPS beim Support ein Upgrade auf MySQL 8.4 anfragen. Wir haben 8.4 getestet, ein Server, der noch auf 8.0 läuft, kann sich also leicht unterscheiden.

Was wir nicht getestet haben: die eigenen MySQL-VPS-Einstellungen von DreamHost, Shared MySQL, Query-Monitor-Zeiten auf einem echten Konto, das Netzwerk zwischen einem Webserver und einem MySQL VPS, WordPress- oder WooCommerce-Tabellen und die Dauer des Umzugs. Jede Zelle lief einmal. Die Diagnoseschritte und Produktdetails stammen aus dem Help Center und den Produktseiten in den Quellen.

FAQ zu langsamen Datenbanken