Datenbank-Wartung und -Optimierung für Online-Shops

Jede dynamische Seite eines Online-Shops entsteht aus Datenbankabfragen. Die Startseite lädt Kategorien, Aktionen und Bestseller, eine Produktseite holt Stammdaten, Varianten, Preise und Bewertungen, der Checkout aggregiert Warenkorb, Versandregeln und Steuersätze. Ist die Datenbank langsam, ist die gesamte Seite langsam -- unabhängig davon, wie gut Frontend und Caching optimiert sind. Die Geschwindigkeit hat direkte Geschäftsauswirkungen: Eine Verzögerung von nur einer Sekunde kann die Conversion-Rate um 7 Prozent senken (Akamai). Pro zusätzlicher Sekunde Ladezeit zwischen 0 und 5 Sekunden sinkt die Conversion-Rate im Schnitt um 4,42 Prozent (Portent, 2019).

Das Problem verschärft sich mit dem Wachstum. Eine Abfrage, die bei 10.000 Bestellungen in Millisekunden antwortet, kann bei 500.000 Bestellungen mehrere Sekunden brauchen -- besonders wenn sie ohne passenden Index über die gesamte Tabelle laufen muss. Der deutsche Online-Handel wuchs 2025 um 3,9 Prozent auf 92,3 Milliarden Euro (HDE), und erfolgreiche Shops sammeln mit jedem Jahr mehr Daten an. Genau hier setzt die proaktive Wartung an: Sie hält die Antwortzeiten konstant niedrig, auch wenn der Datenbestand wächst. Ohne sie verschlechtert sich die Performance schleichend -- oft unbemerkt, bis es im Weihnachtsgeschäft zum Engpass kommt.

Bevor optimiert werden kann, müssen die langsamen Abfragen sichtbar gemacht werden. Das wichtigste Werkzeug dafür ist das Slow Query Log. In MariaDB und MySQL wird es über slow_query_log = ON aktiviert; mit long_query_time = 1 werden alle Abfragen protokolliert, die länger als eine Sekunde dauern (MariaDB-Dokumentation). Besonders aufschlussreich ist die Option log_queries_not_using_indexes, die gezielt Abfragen erfasst, die ohne Index laufen -- denn genau diese lassen sich meist durch einen neuen Index oder eine Umformulierung beheben (MariaDB-Dokumentation).

Das reine Logfile ist nur der Anfang. Werkzeuge wie mysqldumpslow oder pt-query-digest fassen die Einträge zusammen und zeigen, welche Abfragen am längsten dauern und wie oft sie ausgeführt werden (MariaDB-Dokumentation). Diese Kombination aus Dauer und Häufigkeit ist entscheidend: Eine Abfrage, die 0,8 Sekunden dauert, aber bei jedem Seitenaufruf ausgeführt wird, hat einen größeren Gesamteinfluss als eine, die zwei Sekunden braucht, aber nur einmal pro Stunde läuft. Im Datenbank-Audit priorisieren wir deshalb nach Gesamtlast -- und beheben zuerst die Abfragen mit dem größten Hebel, statt blind alle langsamen Queries zu optimieren.

Datenbank-Wartung umfasst immer auch die Datensicherung. Die Datenbank enthält die wertvollsten Daten eines Shops -- Bestellungen, Kunden, Rechnungen -- und ihr Verlust kann existenzbedrohend sein. Die Bitkom-Studie 'Wirtschaftsschutz 2025' zeigt, dass 87 Prozent der deutschen Unternehmen in den vergangenen zwölf Monaten von Datendiebstahl, Spionage oder Sabotage betroffen waren; der Gesamtschaden für die deutsche Wirtschaft lag bei 289,2 Milliarden Euro (Bitkom, 2025). Ein verlässliches Backup ist die letzte Verteidigungslinie -- gegen Hardware-Ausfälle, fehlerhafte Updates, Angriffe und versehentliches Löschen gleichermaßen.

Entscheidend ist nicht das Anlegen, sondern die Wiederherstellbarkeit. Ein Backup, das nie getestet wurde, ist kein Backup, sondern eine Hoffnung. Zur Datenbank-Wartung gehört deshalb der regelmäßige Restore-Test: Die Sicherung wird in einer isolierten Umgebung tatsächlich eingespielt, auf Vollständigkeit geprüft und die Wiederherstellungszeit dokumentiert. Bewährt hat sich die 3-2-1-Regel: drei Kopien der Daten, auf zwei verschiedenen Medientypen, davon eine an einem anderen Ort (Bitkom). Bei Datenbanken kommen zwei Verfahren zusammen: regelmäßige vollständige Dumps und, für minimalen Datenverlust, Point-in-Time-Recovery über die Binärlogs. Mehr dazu in unserem Beitrag zu PHP-Lebenszyklus und sicheren Upgrades, in dem auch der sichere Umgang mit Datenbank-Migrationen eine Rolle spielt.

Wirksame Datenbank-Wartung folgt einem wiederkehrenden Zyklus statt punktueller Eingriffe. Am Anfang steht eine Bestandsaufnahme: Wie groß ist die Datenbank, welche Tabellen dominieren, wie sehen die Slow-Query-Statistiken aus und welche Indizes existieren bereits? Aus dieser Analyse entsteht ein priorisierter Maßnahmenplan. Anschließend werden Optimierungen umgesetzt -- jede zuerst in einer Staging-Umgebung getestet, denn eine geänderte Index-Struktur oder ein großes Cleanup kann in seltenen Fällen unerwartete Nebenwirkungen haben. Erst nach erfolgreichem Test erfolgt die Übertragung auf das Live-System, begleitet von Monitoring.

Danach beginnt der Zyklus von vorne: Die Wirkung der Maßnahmen wird gemessen, die Kennzahlen werden mit der Ausgangslage verglichen, und neue Engpässe werden identifiziert. Dieser kontinuierliche Ansatz unterscheidet die professionelle kontinuierliches Monitoring der Datenbank von einer einmaligen Optimierung, die nach wenigen Monaten verpufft. Wir empfehlen einen vollständigen Datenbank-Audit mindestens einmal pro Quartal sowie ein laufendes Monitoring im Rahmen der regelmäßigen Wartung. Nach größeren Änderungen -- einem Relaunch, neuen Funktionen oder einem Versionssprung des Shop-Systems -- ist ein zusätzlicher Audit sinnvoll, weil sich Abfragemuster und Datenmengen dann häufig deutlich verändern.

Der wirtschaftliche Nutzen ist messbar. Schnellere Abfragen bedeuten schnellere Seiten, und schnellere Seiten bedeuten mehr Conversions und zufriedenere Kunden -- bei einer einzigen Sekunde Verzögerung stehen bereits 7 Prozent der Conversions auf dem Spiel (Akamai). Gleichzeitig senkt eine schlanke, gut indizierte Datenbank den Serverbedarf, weil dieselbe Hardware mehr Anfragen verarbeiten kann. Und ein getestetes Backup-Konzept reduziert das Risiko teurer Ausfälle in einem Umfeld, in dem 87 Prozent der Unternehmen von Sicherheitsvorfällen betroffen sind (Bitkom, 2025). Die kontinuierliche Datenbank-Wartung zahlt sich damit auf drei Ebenen aus: Geschwindigkeit, Kosten und Ausfallsicherheit.