Die Datenbank ist das Herzstück jeder dynamischen Website und oft der größte Performance-Flaschenhals. Eine langsame Datenbank macht jede andere Optimierung zunichte. In diesem umfassenden Guide erfahren Sie, wie Sie MySQL und MariaDB optimal konfigurieren, Queries beschleunigen und Ihre Datenbank dauerhaft leistungsfähig halten.
Warum Datenbank-Performance entscheidend ist
Jeder Seitenaufruf einer CMS-Website wie WordPress, Joomla oder TYPO3 (siehe auch unseren CMS-Vergleich) löst zahlreiche Datenbankabfragen aus – oft 20 bis 100 pro Seitenaufruf. Die Geschwindigkeit dieser Abfragen bestimmt maßgeblich die Ladezeit Ihrer Website. Zusammen mit PHP-Optimierung und Caching bildet die Datenbank-Performance die Basis für eine schnelle Website.
MySQL vs. MariaDB
MariaDB ist ein Fork von MySQL und zu diesem weitgehend kompatibel. Beide sind hervorragende Datenbanksysteme für Webprojekte.
| Merkmal | MySQL | MariaDB |
|---|---|---|
| Entwickler | Oracle | MariaDB Foundation |
| Lizenz | GPL + kommerziell | GPL (vollständig Open Source) |
| Performance | Sehr gut | Sehr gut (teils besser) |
| Kompatibilität | Standard | MySQL-kompatibel + Extras |
| Storage Engines | InnoDB, MyISAM | InnoDB, Aria, ColumnStore, etc. |
| Verbreitung (Hosting) | Sehr hoch | Hoch (Standard bei vielen Linux-Distros) |
Server-Konfiguration: my.cnf optimieren
Die MySQL/MariaDB-Konfiguration in der my.cnf (oder my.ini) hat den größten Einfluss auf die Performance. Die Standardeinstellungen sind bewusst konservativ und für die meisten Produktivumgebungen zu niedrig angesetzt.
Die wichtigsten Einstellungen
| Einstellung | Empfehlung | Erklärung |
|---|---|---|
| innodb_buffer_pool_size | 50-70% des RAM | Wichtigste Einstellung! Puffer für Daten und Indizes |
| innodb_log_file_size | 256M-1G | Größere Logs = bessere Schreibperformance |
| innodb_flush_log_at_trx_commit | 2 | Kompromiss zwischen Sicherheit und Speed |
| innodb_flush_method | O_DIRECT | Vermeidet doppeltes Puffern |
| innodb_io_capacity | 200-2000 | An SSD/HDD anpassen |
| innodb_read_io_threads | 4-8 | Parallele Lesezugriffe |
| innodb_write_io_threads | 4-8 | Parallele Schreibzugriffe |
| max_connections | 100-300 | An erwartete Last anpassen |
| tmp_table_size | 64M | Temporäre Tabellen im RAM |
| max_heap_table_size | 64M | Muss gleich tmp_table_size sein |
| table_open_cache | 2000-4000 | Geöffnete Tabellen im Cache |
| thread_cache_size | 16-32 | Thread-Wiederverwendung |
Buffer Pool richtig dimensionieren
Der InnoDB Buffer Pool ist der wichtigste Performance-Parameter. Er hält Tabellendaten und Indizes im RAM. Ist er zu klein, muss die Datenbank ständig von der Festplatte lesen, was um Größenordnungen langsamer ist. Auf einem dedizierten Datenbankserver mit 16 GB RAM sollten Sie dem Buffer Pool 10-11 GB zuweisen.
Um die optimale Größe zu bestimmen, prüfen Sie die aktuelle Nutzung. Liegt die Buffer-Pool-Hit-Rate unter 99%, ist der Pool zu klein. Dies erfordert einen vServer oder Root-Server mit ausreichend RAM – auf Shared Hosting haben Sie keinen Einfluss auf diese Einstellung. Vergleichen Sie die Hosting-Kosten, um die passende Lösung zu finden.
Indizes: Der Turbo für Abfragen
Indizes sind Datenstrukturen, die das Auffinden von Datensätzen beschleunigen – vergleichbar mit dem Inhaltsverzeichnis eines Buchs. Ohne passende Indizes muss die Datenbank jeden Datensatz einzeln prüfen (Full Table Scan).
Wann ein Index sinnvoll ist
- Spalten in WHERE-Klauseln
- Spalten in JOIN-Bedingungen
- Spalten in ORDER BY und GROUP BY
- Spalten mit hoher Selektivität (viele unterschiedliche Werte)
Wann ein Index schadet
- Tabellen mit wenigen Zeilen (unter 1000)
- Spalten mit wenigen unterschiedlichen Werten (z.B. Boolean)
- Spalten, die häufig geändert werden (jeder Index verlangsamt Schreiboperationen)
- Zu viele Indizes pro Tabelle (mehr als 5-6)
Index-Typen
| Index-Typ | Verwendung | Beispiel |
|---|---|---|
| PRIMARY KEY | Eindeutige Identifikation | id-Spalte |
| UNIQUE | Eindeutige Werte sicherstellen | email, slug |
| INDEX | Häufige Suchspalten | status, category_id |
| COMPOSITE | Mehrere Spalten zusammen | (status, created_at) |
| FULLTEXT | Volltextsuche | title, body |
Query-Optimierung
Selbst mit perfekten Indizes können schlecht geschriebene Queries die Performance ruinieren. Die Analyse mit EXPLAIN zeigt, wie MySQL eine Abfrage ausführt.
Häufige Query-Probleme
- SELECT *: Immer nur benötigte Spalten abfragen
- N+1-Queries: Statt einer Query pro Datensatz einen JOIN verwenden
- Fehlende WHERE-Klauseln: Immer so früh wie möglich filtern
- Subqueries statt JOINs: JOINs sind meist schneller
- LIKE '%text%': Kann keinen Index nutzen, FULLTEXT-Index verwenden
- ORDER BY ohne Index: Erzwingt Sortierung im Arbeitsspeicher
EXPLAIN verwenden
Stellen Sie jeder verdächtigen Query das Schlüsselwort EXPLAIN voran. Die Ausgabe zeigt den Ausführungsplan, verwendete Indizes und die geschätzte Zeilenanzahl. Achten Sie besonders auf:
- type: ALL – Full Table Scan, Index fehlt
- rows – Hohe Zahl deutet auf fehlenden Index
- Extra: Using filesort – Sortierung ohne Index
- Extra: Using temporary – Temporäre Tabelle nötig
Slow Query Log: Probleme finden
Das Slow Query Log protokolliert alle Abfragen, die länger als eine definierte Zeit dauern. Aktivieren Sie es in der Konfiguration und analysieren Sie die Ergebnisse regelmäßig.
- slow_query_log = 1 – Slow Query Log aktivieren
- long_query_time = 1 – Queries über 1 Sekunde loggen
- log_queries_not_using_indexes = 1 – Queries ohne Index loggen
Kombinieren Sie dies mit Server-Monitoring, um Datenbankprobleme frühzeitig zu erkennen.
Regelmäßige Wartung
Datenbanken benötigen regelmäßige Wartung, um optimal zu funktionieren. Erstellen Sie einen Wartungsplan und führen Sie folgende Aufgaben regelmäßig durch:
Wartungsaufgaben
| Aufgabe | Frequenz | Beschreibung |
|---|---|---|
| OPTIMIZE TABLE | Monatlich | Defragmentierung und Platzfreigabe |
| ANALYZE TABLE | Wöchentlich | Statistiken für Query-Optimizer aktualisieren |
| Backup | Täglich | Vollständige Datensicherung |
| Slow Query Review | Wöchentlich | Langsame Queries identifizieren und optimieren |
| Größenüberwachung | Monatlich | Wachstum von Tabellen im Blick behalten |
| Alte Daten bereinigen | Quartalsweise | Revisions, Logs, Sessions aufräumen |
CMS-spezifische Optimierung
WordPress-Datenbank
- Post-Revisionen begrenzen (wp-config.php: AUTOSAVE_INTERVAL, WP_POST_REVISIONS)
- Transients regelmäßig bereinigen
- Spam-Kommentare und Papierkorb leeren
- Autoload-Optionen in wp_options überprüfen
Allgemeine CMS-Tipps
- Session-Tabellen regelmäßig bereinigen
- Cache-Tabellen nicht unnötig groß werden lassen
- Verwaiste Daten nach Plugin-Deinstallation entfernen
Replikation und Hochverfügbarkeit
Für Websites mit hohem Traffic kann eine einzelne Datenbankinstanz zum Flaschenhals werden. MySQL-Replikation verteilt die Last auf mehrere Server.
- Master-Slave-Replikation: Schreiboperationen auf dem Master, Leseoperationen auf Slaves
- Master-Master-Replikation: Schreiboperationen auf beiden Servern (komplexer)
- Galera Cluster: Synchrone Multi-Master-Replikation (MariaDB)
Dies erfordert entsprechende Server-Infrastruktur – lesen Sie mehr über Server-Skalierung und Server-Einrichtung.
Sicherheit nicht vergessen
Neben der Performance sollte die Datenbank auch abgesichert sein. Verwenden Sie starke Passwörter, beschränken Sie den Zugriff auf localhost und halten Sie die Software aktuell. Grundlegendes zur Website-Sicherheit und Firewall-Konfiguration schützt auch Ihre Datenbank. Regelmäßige Backups sind unverzichtbar.
Fazit: Datenbank-Performance systematisch verbessern
Datenbank-Optimierung ist ein systematischer Prozess – besonders wichtig bei datenintensiven Headless-CMS-Architekturen mit API-Endpoints. Beginnen Sie mit der Konfiguration des Buffer Pools und der wichtigsten my.cnf-Einstellungen. Analysieren Sie dann Ihre Queries mit dem Slow Query Log und EXPLAIN, und erstellen Sie fehlende Indizes. Richten Sie regelmäßige Wartung ein und überwachen Sie die Performance kontinuierlich. Zusammen mit PHP-Optimierung, Caching und einem CDN erreichen Sie maximale Website-Performance.
Häufig gestellte Fragen
Wie finde ich heraus, ob meine Datenbank langsam ist?
Aktivieren Sie das Slow Query Log in MySQL oder MariaDB, um alle Abfragen zu protokollieren, die länger als eine bestimmte Zeit dauern. Zusätzlich können Sie den Befehl SHOW PROCESSLIST nutzen, um aktuell laufende Queries zu sehen. Tools wie MySQLTuner analysieren Ihre Konfiguration und geben konkrete Verbesserungsvorschläge.
Was ist der InnoDB Buffer Pool und wie groß sollte er sein?
Der InnoDB Buffer Pool ist ein Speicherbereich, in dem MySQL häufig genutzte Daten und Indizes zwischenspeichert, um Festplattenzugriffe zu vermeiden. Als Faustregel sollte er auf einem dedizierten Datenbankserver etwa 70-80 Prozent des verfügbaren Arbeitsspeichers umfassen. Bei einem vServer mit anderen Diensten sollten Sie entsprechend weniger zuweisen.
Wann sollte ich Indizes für meine Datenbank erstellen?
Indizes sollten für alle Spalten erstellt werden, die häufig in WHERE-Klauseln, JOIN-Bedingungen oder ORDER-BY-Anweisungen verwendet werden. Nutzen Sie EXPLAIN vor Ihren Queries, um zu erkennen, ob ein Full Table Scan durchgeführt wird. Beachten Sie jedoch, dass zu viele Indizes die Schreib-Performance verschlechtern können.
Wie oft sollte ich meine Datenbank warten und optimieren?
Eine regelmäßige Wartung sollte mindestens monatlich durchgeführt werden, bei stark genutzten Datenbanken auch wöchentlich. Dazu gehören das Optimieren fragmentierter Tabellen mit OPTIMIZE TABLE, das Prüfen der Tabellenintegrität und das Bereinigen veralteter Daten. Automatisieren Sie diese Aufgaben am besten über Cronjobs.
Ist MariaDB schneller als MySQL?
MariaDB bietet in vielen Szenarien eine vergleichbare oder leicht bessere Performance als MySQL, insbesondere bei bestimmten Abfragetypen und der Aria-Storage-Engine. Für die meisten Webhosting-Anwendungen sind die Unterschiede jedoch gering. Wichtiger als die Wahl zwischen MySQL und MariaDB ist die richtige Konfiguration und Optimierung der Datenbank.