MariaDB für WordPress optimieren: InnoDB-Pufferspeicher, Slow Query Log und Tabellenpflege

Jeder Seitenaufruf einer WordPress-Website, der nicht aus einem Cache kommt, löst Dutzende Datenbankabfragen aus. Läuft die Datenbank auf einem eigenen Server oder VPS, bestimmen wenige Einstellungen von MariaDB, ob diese Abfragen aus dem Arbeitsspeicher beantwortet werden oder ständig die Festplatte bemühen. Die Voreinstellungen sind bewusst klein gehalten, damit MariaDB auch auf winzigen Maschinen startet. Diese Anleitung zeigt, wie Sie den Ist-Zustand messen, den InnoDB-Pufferspeicher und das Redo-Log passend zu Ihrem Server einstellen, langsame Abfragen sichtbar machen und die Tabellen regelmäßig pflegen. Sie erfahren auch, wo die Grenzen liegen: Bei Shared Hosting haben Sie auf diese Einstellungen keinen Zugriff, und kein Parameter repariert ein Plugin, das schlechte Abfragen schreibt.

Voraussetzungen

• Server: eigener Server oder VPS mit Root-Zugriff per SSH, auf dem MariaDB läuft. Für eine typische Unternehmenswebsite mit WordPress, PHP und Datenbank auf einer Maschine reichen 2 CPU-Kerne und 4 GB RAM.
• Versionen: WordPress 7.1 und MariaDB 11.8 LTS. Die Einstellungen gibt es auch in älteren Versionen, einzelne Details wie das Vergrößern des Pufferspeichers im laufenden Betrieb unterscheiden sich aber je nach Unterversion.
• WP-CLI auf dem Server für die Befehle in Schritt 1 und 5, alternativ der Client mariadb.
• Rolle: Administrator in WordPress und ein Datenbankbenutzer mit Rechten auf die WordPress-Datenbank; für globale Einstellungen der Root-Zugang zu MariaDB.
• Backup: eine aktuelle Sicherung von Datenbank und Dateien, bevor Sie Konfiguration oder Tabellen ändern.

Bei Shared Hosting verwaltet der Anbieter MariaDB für viele Kunden gemeinsam. Dort bleiben Ihnen die Schritte 1 und 5 sowie das Aufräumen der Daten selbst, das die Anleitung WordPress-Datenbank aufräumen beschreibt.

Schritt 1: Ausgangslage messen

Ohne Zahlen raten Sie. Zwei Werte genügen für den Anfang: wie groß die WordPress-Daten sind und wie oft MariaDB eine Seite nicht im Arbeitsspeicher findet. WP-CLI zeigt die Größe je Tabelle:

wp db size --tables --human-readable

Die Gesamtgröße aller InnoDB-Tabellen auf dem Server, also auch anderer Websites, liefert eine Abfrage an das Informationsschema:

sudo mariadb -e "SELECT ROUND(SUM(data_length+index_length)/1048576) AS mb FROM information_schema.tables WHERE engine='InnoDB';"

Dann die aktuellen Einstellungen und die Zähler des Pufferspeichers:

sudo mariadb -e "SELECT VERSION(), @@innodb_buffer_pool_size/1048576 AS pool_mb, @@innodb_log_file_size/1048576 AS redo_mb, @@slow_query_log;"
sudo mariadb -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';"

Innodb_buffer_pool_read_requests zählt alle Lesezugriffe, Innodb_buffer_pool_reads nur die, für die MariaDB auf den Datenträger musste. Teilen Sie den zweiten Wert durch den ersten: Je näher das Ergebnis an null liegt, desto besser passt der Pufferspeicher. Die Zähler beginnen bei jedem Neustart von vorn; messen Sie erst nach einigen Stunden Betrieb. Auf einer frisch installierten MariaDB 11.8 stehen der Pufferspeicher auf 128 MB und das Redo-Log auf 96 MB.

Verifizieren: Sie kennen die Datengröße in MB, die aktuelle Größe des Pufferspeichers und das Verhältnis der beiden Lesezähler. Notieren Sie die Werte, um später vergleichen zu können.

Schritt 2: InnoDB-Pufferspeicher dimensionieren

Der Pufferspeicher (Buffer Pool) hält Tabellen- und Indexseiten im RAM. Ist er größer als Ihre Daten, liest MariaDB nach dem Aufwärmen praktisch nur noch aus dem Speicher. Die MariaDB-Dokumentation nennt bis zu 80 Prozent des Arbeitsspeichers, meint damit aber einen Server, der nur die Datenbank betreibt. Auf einem typischen WordPress-Server teilen sich Webserver, PHP-FPM mit mehreren Prozessen, ein eventueller Redis-Cache und das Betriebssystem denselben Speicher. Nimmt die Datenbank zu viel, muss das System auslagern, und die Website wird langsamer statt schneller.

Eine praxistaugliche Faustregel für eine gemeinsam genutzte Maschine: Datengröße plus etwa 50 Prozent Reserve für Wachstum, gedeckelt bei rund einem Viertel des RAM. Bei 4 GB RAM und 150 MB Daten sind 512 MB großzügig. Wenn Ihre Daten größer sind als ein Viertel des Speichers, ist mehr RAM oder ein Aufräumen der Datenbank die bessere Antwort als ein Pufferspeicher, der PHP verdrängt. Wie Sie den Speicherbedarf von PHP abschätzen, zeigt WordPress-Hosting-Ressourcen prüfen.

Der Wert lässt sich laut Dokumentation im laufenden Betrieb ändern:

sudo mariadb -e "SET GLOBAL innodb_buffer_pool_size = 512*1024*1024; SELECT @@innodb_buffer_pool_size/1048576;"

Nach oben begrenzt das die schreibgeschützte Variable innodb_buffer_pool_size_max. Laut MariaDB-Dokumentation liegt sie ab 11.8.7 auf 64-Bit-Systemen standardmäßig so hoch, dass das Vergrößern ohne Neustart klappt. In älteren Unterversionen entspricht sie dem Startwert. Dann kommt statt einer Fehlermeldung nur eine Warnung, und der Wert bleibt, wie er war:

Warning	1292	Truncated incorrect innodb_buffer_pool_size value: '1073741824'

Prüfen Sie nach SET GLOBAL deshalb immer mit SELECT, ob der Wert tatsächlich übernommen wurde. Dauerhaft wird die Änderung erst durch die Konfigurationsdatei im nächsten Schritt.

Verifizieren: SELECT @@innodb_buffer_pool_size/1048576 zeigt den gewünschten Wert in MB, und free -m lässt nach dem Aufwärmen noch Luft für PHP und Betriebssystem.

Schritt 3: Einstellungen dauerhaft in einer eigenen Datei festlegen

Unter Debian und Ubuntu liest MariaDB alle Dateien in /etc/mysql/mariadb.conf.d/ in alphabetischer Reihenfolge. Ändern Sie nicht die mitgelieferte 50-server.cnf, sondern legen Sie eine eigene Datei mit höherer Nummer an. So überschreibt ein Paketupdate Ihre Werte nicht, und Sie sehen auf einen Blick, was vom Standard abweicht.

sudo nano /etc/mysql/mariadb.conf.d/99-wordpress.cnf

[mariadbd]
innodb_buffer_pool_size = 512M
innodb_log_file_size    = 128M
slow_query_log          = ON
slow_query_log_file     = /var/log/mysql/mariadb-slow.log
long_query_time         = 1

Zum Redo-Log: Es nimmt Änderungen auf, bevor sie in die eigentlichen Tabellendateien geschrieben werden. Ein größeres Log bedeutet laut Dokumentation weniger Schreibarbeit auf dem Datenträger, aber eine längere Wiederherstellung nach einem Absturz. Eine WordPress-Website schreibt im Vergleich zu einem Shop wenig; der Standard von 96 MB reicht meist, 128 bis 256 MB schaden nicht. Seit MariaDB 10.9 lässt sich auch dieser Wert im Betrieb ändern, beim nächsten Start passt MariaDB die Datei an den Konfigurationswert an.

Lassen Sie innodb_flush_log_at_trx_commit auf dem Standard 1. Nur dieser Wert schreibt jede abgeschlossene Transaktion sofort sicher auf den Datenträger. Kleinere Werte beschleunigen Schreibvorgänge, riskieren aber bei einem Stromausfall die letzten Bestellungen oder Formulareingaben.

Legen Sie das Log-Verzeichnis an, prüfen Sie die Konfiguration und starten Sie den Dienst neu:

sudo install -d -o mysql -g mysql /var/log/mysql
my_print_defaults --mysqld
sudo systemctl restart mariadb

my_print_defaults zeigt alle Werte, die MariaDB beim Start lesen wird. Ein Tippfehler fällt dort noch nicht auf, wohl aber beim Start (siehe Typische Fehler).

Verifizieren: systemctl status mariadb meldet active (running), und sudo mariadb -e "SELECT @@innodb_buffer_pool_size/1048576, @@innodb_log_file_size/1048576, @@slow_query_log;" zeigt 512, 128 und 1.

Schritt 4: Langsame Abfragen sichtbar machen

Das Slow Query Log schreibt jede Abfrage mit, die länger als long_query_time Sekunden dauert. Der Standard von 10 Sekunden ist für eine Website zu hoch: Eine Abfrage, die eine Sekunde braucht, bremst schon jeden Seitenaufruf spürbar. Mit der Einstellung aus Schritt 3 landen solche Abfragen im Log. Einen Eintrag sehen Sie, wenn Sie gezielt eine langsame Abfrage auslösen:

sudo mariadb -e "SELECT SLEEP(1.5);"
sudo tail -n 7 /var/log/mysql/mariadb-slow.log

# User@Host: root[root] @ localhost []
# Query_time: 1.501422  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
SELECT SLEEP(1.5);

Nach ein paar Tagen Betrieb fasst mariadb-dumpslow gleichartige Abfragen zusammen und sortiert sie nach Gesamtzeit:

sudo mariadb-dumpslow -s t -t 10 /var/log/mysql/mariadb-slow.log

Die Zusammenfassung zeigt, welche Abfrage wie oft kam und wie lange sie insgesamt lief. Achten Sie auf hohe Werte bei Rows_examined: Dann durchsucht MariaDB ganze Tabellen, oft wp_postmeta oder wp_options. Die Ursache sitzt fast immer in einem Plugin oder Theme, nicht in der Datenbankkonfiguration. Welches Plugin die Abfrage absetzt, zeigt Ihnen Query Monitor; das Vorgehen steht in Langsame Plugins finden mit Query Monitor. Stellen Sie das Log nach der Analyse wieder ab oder lassen Sie es von logrotate kürzen, sonst wächst die Datei unbegrenzt.

Verifizieren: Die Log-Datei existiert, enthält Einträge mit Query_time, und mariadb-dumpslow gibt eine Zusammenfassung mit Count: und Time= aus.

Schritt 5: Tabellen prüfen und regelmäßig pflegen

InnoDB repariert sich nach Abstürzen in der Regel selbst. Eine Prüfung schadet trotzdem nicht und dauert bei WordPress-Datenbanken nur Sekunden:

wp db check

Jede Tabelle sollte mit OK enden, am Schluss steht Success: Database checked.

Wenn Sie viele Daten gelöscht haben, etwa alte Revisionen, Spam-Kommentare oder Protokolle eines entfernten Plugins, gibt InnoDB den Platz nicht automatisch an das Dateisystem zurück. Hier hilft das Optimieren:

wp db export vor-optimize.sql
wp db optimize

Die Meldung Table does not support optimize, doing recreate + analyze instead ist bei InnoDB normal und kein Fehler: MariaDB baut die Tabelle neu auf und aktualisiert die Statistiken, die der Abfrageplaner nutzt. Planen Sie das außerhalb der Hauptgeschäftszeit ein, denn bei großen Tabellen dauert der Neuaufbau und braucht vorübergehend zusätzlichen Speicherplatz.

Datenbankpflege ist keine einmalige Aufgabe. Die Datengröße wächst, Plugins kommen hinzu, und nach jedem MariaDB-Update lohnt ein Blick, ob die Werte noch passen. Wer diese Termine nicht selbst im Kalender halten möchte, kann einen Teil davon abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt die Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung sowie wöchentliche Backups auf externen Speicher, sodass vor jeder Wartungsaktion eine frische Sicherung bereitliegt.

Verifizieren: wp db size --tables --human-readable zeigt nach dem Optimieren für die bereinigten Tabellen kleinere Werte als in Schritt 1, die Website lädt normal.

Typische Fehler

• MariaDB startet nach der Änderung nicht: Meist ein Tippfehler im Variablennamen. Im Journal (journalctl -u mariadb) steht dann zum Beispiel [ERROR] mariadbd: unknown variable 'innodb_bufer_pool_size=512M'. Korrigieren Sie die Zeile in Ihrer eigenen Datei und starten Sie erneut; die Daten sind davon nicht betroffen.
• Der neue Wert greift nicht: Die Einstellung steht im falschen Abschnitt oder wird von einer Datei mit höherer Nummer überschrieben. my_print_defaults --mysqld zeigt, welcher Wert zuletzt gelesen wird; der letzte gewinnt.
• Warnung 1292 bei SET GLOBAL: Der Wert liegt über innodb_buffer_pool_size_max. Tragen Sie den Wert in die Konfigurationsdatei ein und starten Sie MariaDB neu.
• Server lagert aus, Website wird langsamer: Der Pufferspeicher ist zu groß für die Maschine. Prüfen Sie mit free -m den verfügbaren Speicher und reduzieren Sie den Wert, bis wieder Reserve bleibt.
• Slow Query Log bleibt leer: Das Verzeichnis gehört nicht dem Benutzer mysql, oder MariaDB wurde nach der Änderung nicht neu gestartet. Prüfen Sie @@slow_query_log und die Rechte von /var/log/mysql.
• mariadb-dumpslow endet mit „Died at … line 185“: Im Test lieferte das Werkzeug die Zusammenfassung trotzdem vollständig aus und brach erst am Ende mit dieser Meldung ab. Werten Sie die ausgegebene Liste aus; fehlt sie ganz, prüfen Sie Pfad und Leserechte der Log-Datei.

Häufige Fragen

Bringt der Query Cache von MariaDB etwas für WordPress?

In MariaDB 11.8 ist er standardmäßig ausgeschaltet (query_cache_type steht auf OFF). Für WordPress wirken ein Page-Cache und ein Object Cache mit Redis deutlich gezielter, weil sie ganze Seiten oder Objekte vorhalten statt einzelner Abfrageergebnisse.

Wie groß darf der Pufferspeicher höchstens sein?

Auf einem reinen Datenbankserver nennt die MariaDB-Dokumentation bis zu 80 Prozent des RAM. Laufen Webserver und PHP auf derselben Maschine, sollte deutlich mehr Speicher frei bleiben. Größer als die Daten plus Wachstumsreserve bringt keinen Vorteil.

Muss ich MyISAM-Tabellen umwandeln?

WordPress legt seine Tabellen mit der Standard-Engine an, bei MariaDB ist das InnoDB. Ältere Plugins oder sehr alte Installationen können noch MyISAM-Tabellen haben. Diese profitieren nicht vom InnoDB-Pufferspeicher. Die Abfrage aus Schritt 1 mit engine='MyISAM' zeigt, ob welche vorhanden sind. Testen Sie eine Umstellung zuerst auf einer Kopie.

Wie oft sollte ich die Tabellen optimieren?

Nach großen Löschaktionen und sonst ein paar Mal im Jahr. Häufigeres Optimieren erzeugt Last, ohne die Website messbar schneller zu machen.

Testumfang

Wir haben die Schritte auf einer Testinstallation mit WordPress 7.1.2 und MariaDB durchgespielt und den Pufferspeicher im Betrieb sowie per Konfigurationsdatei vergrößert. Auffällig war, dass eine ältere MariaDB-Unterversion das Vergrößern im Betrieb nur mit einer Warnung quittiert und den alten Wert behält.

Echten Besucherverkehr und große Shop-Datenbanken haben wir nicht nachgestellt. Übertragen Sie die Werte deshalb schrittweise und messen Sie nach jeder Änderung.

Fazit

Für die meisten WordPress-Websites auf eigenem Server genügen drei Handgriffe: den Pufferspeicher an die Datengröße anpassen, langsame Abfragen protokollieren und die Tabellen nach größeren Aufräumaktionen neu aufbauen. Die größten Gewinne kommen ohnehin selten aus der Konfiguration, sondern aus dem Entfernen überflüssiger Daten und dem Ersetzen von Plugins mit teuren Abfragen. Wenn Sie Updates und Backups rund um solche Eingriffe lieber abgeben, übernimmt das die WordPress-Wartung mit persönlicher Betreuung durch Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Autoload-Optionen in der WordPress-Datenbank analysieren und verkleinern
• WordPress-Datenbank auf MariaDB aktualisieren
• WordPress-Datenbank mit WP-CLI sichern und wiederherstellen
• MariaDB-Dokumentation: InnoDB Buffer Pool
• MariaDB-Dokumentation: InnoDB-Systemvariablen
• WP-CLI-Handbuch: wp db