Schwarzer Freitag. WordPress + WooCommerce auf einem VPS. Die Homepage wird in zwölf Sekunden geladen – nicht aufgrund des viralen Datenverkehrs, sondern aufgrund einer „Postmeta“-Tabelle ohne Indizes und einer austauschbaren MySQL-Festplatte. Gleichzeitig wurde die automatische „Speicherung“ nie wiederhergestellt; Der letzte Dump war vor sechs Tagen. Der Grundstein hätte vor der Krise gelegt werden sollen, nicht nach der Obduktion.
MySQL auf einer dynamischen Site wird nicht „vom Host installiert und daher reguliert“. Dies ist das transaktionale Herzstück Ihres Umsatzes – Katalog, Bestellungen, Kundenkonten. Vier Säulen halten die Produktion aufrecht: gesunde Engine, begrenzte Konten, indizierte Abfragen, bewährte Backups.
Engine und Zeichensatz reinigen
Überprüfen Sie zunächst, was Ihre Anwendung tatsächlich verwendet:
- InnoDB obligatorisch für Geschäftstabellen – Transaktionen, Wiederherstellung nach einem Absturz, Fremdschlüssel.
- utf8mb4 für Emojis und alle Unicode-Zeichen; nicht das alte „utf8“, gekürzt auf drei Bytes.
- Konsistente Sortierung über alle Tabellen hinweg – vermeidet langsame implizite Verknüpfungen.
Überprüfen Sie die Legacy-Tabellen:
„sql SHOW TABLE STATUS WHERE Engine != 'InnoDB';
Konvertieren Sie MyISAM vor dem nächsten Stromausfall – nicht an dem Tag, an dem ein Ausfall eine Tabelle ohne Transaktionsprotokoll beschädigt.
## Konten und Angriffsfläche
Ein einzelner „root“-Benutzer in der „.env“-Datei von WordPress oder Laravel ist eine häufige schlechte Praxis:
| Konto | Rechte | Verwendung |
| --- | --- | --- |
| `app_user` | CRUD nur auf „app_db“ | PHP, WordPress, Anwendung |
| `backup_user` | AUSWÄHLEN + SPERREN oder Dump-Tool | Backup-Cron |
| `root` | ALLE | Lokale menschliche Verwaltung, nicht in „.env“ |
Kein Benutzer „%“ über das Internet erreichbar. Verknüpfen Sie MySQL nach Möglichkeit mit Localhost oder einem privaten Netzwerk – siehe [VPS-Firewall](/de/blog/pare-feu-vps/). Ein kompromittiertes Anwendungskonto sollte nicht in der Lage sein, die Datenbank zu löschen.
:::Hinweis
**Denken Sie daran.** Die Verdoppelung der Größe des VPS ohne Analyse langsamer Anfragen bedeutet, dass die Langsamkeit auf den doppelten Preis steigt.
:::
## Leistung vor Hardware
Messen Sie vor dem Upgrade des Servers Folgendes:
– **Protokoll langsamer Abfragen** aktiviert mit einem Schwellenwert von 1–2 Sekunden; jede Woche analysieren.
- **Index** für WHERE- und JOIN-Klauselspalten – kein Index für alle Spalten.
- **InnoDB-Pufferpool** bei etwa 70 % des dedizierten MySQL-RAM auf einem reinen Datenbank-VPS.
- **Abfrage-Cache** – veraltet unter MySQL 8; Versuchen Sie nicht, es wieder zu aktivieren.
Aktivieren Sie in WordPress einen Objektcache ([Redis](/de/blog/redis-application-web/)) **nach** der SQL-Bereinigung – nicht vorher. Ein Cache, der eine Abfrage zwölf Sekunden lang verbirgt, verschiebt das Problem, löst es aber nicht.
## Bewährte Backups und Wiederherstellung
Ein Backup, das noch nie getestet wurde, ist kein Backup:
- **mysqldump** täglich verschlüsseltes Offsite + Binlog, wenn eine Point-in-Time-Wiederherstellung erforderlich ist.
- **Snapshot**-Festplatte, wenn MySQL lokal auf dem VPS ausgeführt wird.
- **Restaurierungstest** vierteljährlich – siehe [Restaurierung testen](/de/blog/tester-restauration/).
- Dokumentieren Sie die MySQL-Version des Dumps im Vergleich zum Wiederherstellungsziel.
Im Shared-Modus laufen Exporte über das Panel oder einen Cron, wenn SSH verfügbar ist – überprüfen Sie die maximale Größe und Ausschlüsse. Vergleichen Sie die Angebote mit verwaltetem MySQL über das [Verzeichnis](/de/verzeichnis/) und den [Vergleicher](/de/vergleich/), wenn hohe Verfügbarkeit ein Problem darstellt.
## Replikation und Hochverfügbarkeit – nur bei Bedarf
Ein schreibgeschütztes Replikat für die Berichterstellung: nützlich. Automatisches Failover: erhebliche Betriebskomplexität – oft ist verwaltetes MySQL rationaler. Replizieren Sie nicht, um ohne ein getestetes Failover-Runbook „professionell“ auszusehen.
Bewerten Sie während einer Stack-Neugestaltung auch [Postgres verwaltet](/de/blog/postgres-manage/) – die Migration lohnt sich, wenn Ihr Team die Gelegenheit nutzt, das Schema zu überdenken.
## Der Gipfel: Die Basis hält bis zum ersten echten Gipfel
Folgendes verrät die lokale Entwicklung nicht.
:::Höhepunkt
**MySQL „was in dev genug war“ bricht in prod beim ersten Join ohne Index multipliziert mit dem Marketing-Traffic ab.** Am großen Tag liest niemand die langsamen Protokolle – wir aktualisieren den VPS und kopieren das Problem. Die Grundlagen sind nicht spektakulär; Sie machen den Unterschied zwischen einem zwanzigminütigen Zusammenbruch und einer ruhigen Genesung aus.
:::
Fragen Sie sie vor Kampagnen, Migrationen oder Verkäufen – nicht nach dem ersten versehentlichen DROP.
## Entscheide dich und gehe ohne blinden Fleck voran
An einem Tag können Sie den Grundstein legen:
1. **Prüfung** MySQL-Engine, Zeichensatz und Konten – MyISAM konvertieren, Root aus „.env“ entfernen.
2. **Aktivieren** Sie das Protokoll für langsame Abfragen und beheben Sie die drei langsamsten Abfragen.
3. **Automatisieren** Sie ein tägliches verschlüsseltes Backup und planen Sie eine vierteljährliche Testwiederherstellung.
4. **Isolieren** MySQL auf Localhost oder privatem Netzwerk – schließen Sie den direkten Internetzugriff.
5. **Vergleichen** MySQL und MySQL-Hosts, die über das [Verzeichnis](/de/verzeichnis/) verwaltet werden, wenn Auslastung oder Compliance dies erfordern.
Für den allgemeinen Rahmen von Backups gehen Sie zu [Backup-Strategie](/de/blog/strategie-sauvegarde/), sobald der automatische Dump eingerichtet ist.
## Häufig gestellte Fragen
### MyISAM im Jahr 2026 noch akzeptabel?
Nein für Geschäftsdaten. InnoDB überall: Transaktionen, Wiederherstellung nach einem Absturz, Fremdschlüssel. Konvertieren Sie alte Tabellen vor dem nächsten Ausfall – MyISAM protokolliert keine Transaktionen.
### Nur ein MySQL-Root-Benutzer für die App?
Schlechte Praxis. Erstellen Sie einmalig ein Anwendungskonto mit eingeschränkten Rechten (AUSWÄHLEN, EINFÜGEN, AKTUALISIEREN, DELETE). Reservieren Sie die Wurzel für die lokale menschliche Verwaltung oder über eine Bastion.
### Mysqldump oder Snapshot-Backup?
Die beiden ergänzen sich: tragbarer logischer Dump plus schneller Festplatten-Snapshot. Testen Sie die Wiederherstellung – ein Dump, der nie wiederhergestellt wurde, ist keine Versicherung.
### Wann sollte auf verwaltetes MySQL umgestellt werden?
Immer wenn Hochverfügbarkeit, punktuelle Wiederherstellung oder Sicherheitsupdates außerhalb Ihrer Kontrolle liegen – oder bei einer Neufassung auf [verwaltetes Postgres](/de/blog/postgres-manage/).
---
MySQL für eine dynamische Site: Dies ist nicht die angezeigte Version – es ist **InnoDB, begrenzte Konten, Indizes und bewährte Wiederherstellung**, bevor die Krise Ihnen das Vokabular beibringt.