Datenbank-Healthcheck: Checkliste fuer Magento-Shops

1. Warum ein regelmaessiger Datenbank-Healthcheck zaehlt

Die meisten Datenbankprobleme in Magento-Shops entstehen nicht ploetzlich, sondern schleichend: Der Buffer Pool wird relativ zur wachsenden Datenmenge zu klein, ein neues Feature fuehrt eine ungenuegend indizierte Query ein, Replikationslag baut sich unter Lastspitzen langsam auf. Ein strukturierter Datenbank-Healthcheck in regelmaessigen Abstaenden macht genau diese schleichenden Verschlechterungen sichtbar, bevor sie zu einem sichtbaren Vorfall werden.

Der Unterschied zwischen reaktivem und proaktivem Datenbankbetrieb liegt fast immer in der Regelmaessigkeit dieses Checks. Ein Team, das erst beim Auftreten spuerbarer Latenz in die Datenbank schaut, reagiert grundsaetzlich zu spaet, weil viele der zugrundeliegenden Probleme, etwa Tabellenbloat oder fehlende Indizes, sich ueber Wochen oder Monate aufgebaut haben. Ein monatlicher oder quartalsweiser Datenbank-Healthcheck mit einer festen Checkliste verwandelt dieses reaktive Muster in einen planbaren Wartungsprozess.

Diese Checkliste deckt fuenf zentrale Bereiche ab, die in praktisch jedem Datenbank-Healthcheck fuer Magento-Shops vorkommen sollten: Speicherdimensionierung, Query-Performance, Replikationsgesundheit, physische Tabellenqualitaet und die Verifikation, dass Backups im Ernstfall tatsaechlich funktionieren. Jeder dieser Bereiche wird im Folgenden mit konkreten SQL-Abfragen und Zielwerten unterlegt.

2. InnoDB Buffer Pool: Sizing und Hitrate richtig interpretieren

Der InnoDB Buffer Pool cached Tabellen- und Indexdaten im Arbeitsspeicher und ist die wichtigste einzelne Stellschraube fuer die Lesegeschwindigkeit einer Magento-Datenbank. Ein zentraler Pruefpunkt in jedem Datenbank-Healthcheck ist die Buffer Pool Hitrate: Sie zeigt, wie oft eine Anfrage aus dem Speicher statt von der Festplatte bedient wird.

-- Buffer Pool Hitrate berechnen, Zielwert im laufenden Betrieb ueber 99 Prozent
SELECT
    (1 - (
        (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads')
        /
        (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
    )) * 100 AS buffer_pool_hit_rate_pct;

-- Aktuelle Buffer-Pool-Groesse und Auslastung pruefen
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SELECT
    ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS total_innodb_data_gb
FROM information_schema.tables
WHERE engine = 'InnoDB';

Eine Hitrate unter 99 Prozent im normalen Tagesbetrieb, also ausserhalb frisch gestarteter Server mit kaltem Cache, deutet fast immer auf einen zu klein dimensionierten Buffer Pool hin. Als Faustregel gilt fuer dedizierte Datenbankserver: innodb_buffer_pool_size sollte etwa siebzig bis achtzig Prozent des verfuegbaren Arbeitsspeichers betragen, mit ausreichend Reserve fuer Verbindungen, Sortierpuffer und das Betriebssystem selbst. Ein Datenbank-Healthcheck sollte diese Kennzahl immer im Verhaeltnis zur Gesamtdatengroesse aus information_schema.tables betrachten, weil ein Buffer Pool, der kleiner als die aktive Arbeitsmenge ist, strukturell keine hohe Hitrate erreichen kann.

3. Slow-Query-Log und pt-query-digest im Healthcheck-Workflow

Jeder gruendliche Datenbank-Healthcheck braucht eine aktuelle Slow-Query-Analyse, weil sich Query-Muster mit jedem Release, jeder neuen Extension und jeder Aenderung an der Produktpalette verschieben koennen. Eine Query, die vor sechs Monaten schnell war, kann heute bei zehnfacher Datenmenge zum Flaschenhals werden, ohne dass sich am Code etwas geaendert hat.

-- Slow-Query-Logging fuer den Healthcheck-Zeitraum aktivieren
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- Nach Sammelzeitraum: die zehn teuersten Query-Muster nach Gesamtzeit
-- (Auswertung erfolgt separat mit pt-query-digest auf dem Logfile)

-- Aktuell laufende, potenziell haengende Queries direkt pruefen
SELECT id, user, host, db, time, state, LEFT(info, 100) AS query_preview
FROM information_schema.processlist
WHERE command != 'Sleep'
ORDER BY time DESC
LIMIT 20;

Im Rahmen des Datenbank-Healthchecks reicht es meist, das Slow-Query-Log fuer ein bis zwei Stunden waehrend eines typischen Lastfensters zu aktivieren und anschliessend mit pt-query-digest aus dem Percona Toolkit auszuwerten. Ziel ist nicht die Analyse jeder einzelnen Query, sondern das Erkennen struktureller Verschiebungen: Tauchen neue Query-Muster in den Top Zehn auf, die beim letzten Healthcheck noch nicht relevant waren? Das ist oft der fruehste Indikator fuer ein wachsendes Performance-Problem.

4. Replikationslag erkennen, bevor er den Shop beeintraechtigt

Fuer Magento-Shops mit Read-Replicas fuer Storefront oder Reporting gehoert die Replikationslag-Pruefung zu den kritischsten Punkten in jedem Datenbank-Healthcheck. Ein Lag von mehreren Sekunden bedeutet, dass Kunden auf der Replica veraltete Preise, Lagerbestaende oder Bestellstatus sehen koennen, was direkt zu Supportanfragen und Vertrauensverlust fuehrt.

-- Replikationsstatus und Lag auf der Replica pruefen (MySQL 8.0)
SHOW REPLICA STATUS\G
-- Zielwert: Seconds_Behind_Source sollte im Normalbetrieb 0 bis 1 sein

-- Historischen Lag-Verlauf ueber performance_schema auswerten
SELECT
    CHANNEL_NAME,
    SERVICE_STATE,
    COUNT_TRANSACTIONS_IN_QUEUE,
    LAST_QUEUED_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker;

Ein einmaliger kurzer Lag-Spike waehrend eines grossen Batch-Jobs oder eines Reindex-Laufs ist meist unkritisch, solange der Wert danach wieder auf null zurueckgeht. Kritisch wird es, wenn der Datenbank-Healthcheck einen konstant erhoehten Lag ueber laengere Zeitraeume zeigt, weil das auf eine strukturelle Ueberlastung der Replica hindeutet, etwa durch zu schwache Hardware im Verhaeltnis zur Schreiblast des Primary oder durch konkurrierende Leseoperationen, die selbst zu viel I/O verursachen.

5. Tabellenbloat und Fragmentierung: wann OPTIMIZE TABLE hilft

Tabellenbloat entsteht durch geloeschte oder aktualisierte Zeilen, die InnoDB physisch nicht sofort komprimiert. Ein Datenbank-Healthcheck sollte regelmaessig pruefen, wie gross der Anteil an freiem, aber noch belegtem Speicherplatz innerhalb der wichtigsten Magento-Tabellen ist.

-- Fragmentierung der wichtigsten Magento-Tabellen pruefen
SELECT
    table_name,
    ROUND(data_length / 1024 / 1024, 1) AS data_mb,
    ROUND(data_free / 1024 / 1024, 1) AS free_mb,
    ROUND(data_free / NULLIF(data_length, 0) * 100, 1) AS fragmentation_pct
FROM information_schema.tables
WHERE table_schema = 'magento_prod'
  AND data_length > 100 * 1024 * 1024
ORDER BY fragmentation_pct DESC
LIMIT 15;

Eine Fragmentierung ueber zehn bis fuenfzehn Prozent auf grossen Tabellen ist ein guter Schwellenwert, um OPTIMIZE TABLE in den naechsten Wartungsplan aufzunehmen. Da OPTIMIZE TABLE selbst I/O-intensiv ist und bei InnoDB effektiv die Tabelle neu aufbaut, sollte dieser Schritt im Datenbank-Healthcheck nur als Empfehlung dokumentiert und ausserhalb der Stosszeiten separat ausgefuehrt werden, nicht als automatischer Teil des Checks selbst.

6. Backup-Verifikation: Restore-Tests statt Blindvertrauen

Ein Backup, dessen Wiederherstellbarkeit nie getestet wurde, ist im Ernstfall ein reines Risiko, kein Sicherheitsnetz. Der wohl am haeufigsten uebersprungene Punkt in jedem Datenbank-Healthcheck ist deshalb der dokumentierte Restore-Test: das tatsaechliche Einspielen eines aktuellen Backups in eine isolierte Testumgebung und die Verifikation, dass Magento darauf startet und konsistente Daten liefert.

Ein vollstaendiger Backup-Verifikationszyklus im Rahmen des Datenbank-Healthchecks umfasst mindestens drei Schritte: Erstens die Pruefung, dass das automatisierte Backup-Skript tatsaechlich fehlerfrei durchlaeuft und die erwartete Dateigroesse produziert, was ueber ein einfaches Monitoring der letzten erfolgreichen Backup-Zeitstempel realisiert werden kann. Zweitens ein monatlicher Restore-Test in eine isolierte Umgebung mit anschliessender Stichprobenpruefung kritischer Tabellen wie sales_order und catalog_product_entity. Drittens die Messung der tatsaechlichen Restore-Zeit, um im Ernstfall eine realistische Erwartung an die Wiederherstellungsdauer zu haben, statt diese erst waehrend eines echten Ausfalls zu entdecken.

7. Indizes und Statistiken: ANALYZE TABLE und ungenutzte Indizes

Veraltete Tabellenstatistiken fuehren dazu, dass der MySQL Query Optimizer suboptimale Ausfuehrungsplaene waehlt, selbst wenn theoretisch der passende Index vorhanden ist. Ein Datenbank-Healthcheck sollte deshalb pruefen, wie aktuell die Statistiken der am haeufigsten abgefragten Tabellen sind, und bei Bedarf ein ANALYZE TABLE anstossen.

-- Statistiken fuer den Query-Optimizer aktualisieren
ANALYZE TABLE catalog_product_entity, sales_order, quote;

-- Ungenutzte Indizes identifizieren, die nur Schreiblast verursachen
SELECT
    object_schema,
    object_name,
    index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE index_name IS NOT NULL
  AND count_star = 0
  AND object_schema = 'magento_prod'
ORDER BY object_name;

Ungenutzte Indizes sind ein oft uebersehener Punkt im Datenbank-Healthcheck: Sie kosten bei jedem INSERT und UPDATE zusaetzliche Schreibzeit und belegen Speicherplatz, ohne jemals eine Leseanfrage zu beschleunigen. Die obige Abfrage gegen performance_schema.table_io_waits_summary_by_index_usage zeigt Indizes, die seit dem letzten Server-Neustart nie fuer eine Leseoperation genutzt wurden, und ist ein guter Ausgangspunkt fuer eine gezielte Bereinigung, sollte aber vor dem tatsaechlichen Loeschen immer mit einem laengeren Beobachtungszeitraum abgesichert werden.

8. Konfigurationsreview: my.cnf-Parameter fuer Magento

Neben dem Buffer Pool gibt es weitere MySQL-Parameter, die im Rahmen eines Datenbank-Healthchecks regelmaessig gegen aktuelle Lastwerte geprueft werden sollten. innodb_log_file_size beeinflusst, wie oft InnoDB Checkpoints schreiben muss, und ein zu kleiner Wert kann bei hoher Schreiblast im Checkout zu spuerbaren Latenzspitzen fuehren. max_connections sollte zur tatsaechlichen Anzahl paralleler PHP-FPM-Worker und Cron-Prozesse passen, weder zu knapp noch unnoetig ueberdimensioniert.

table_open_cache und table_definition_cache sind bei Magentos vielen hundert Tabellen, insbesondere den EAV-Wertetabellen, oft zu niedrig konfiguriert, was zu wiederholtem Oeffnen und Schliessen von Tabellendeskriptoren fuehrt. Ein Datenbank-Healthcheck sollte den Status Opened_tables im Verhaeltnis zur Serverlaufzeit betrachten: Ein kontinuierlich steigender Wert deutet auf einen zu kleinen table_open_cache hin und ist ein einfach zu behebendes, aber leicht uebersehenes Performance-Problem.

9. Die vollstaendige Healthcheck-Checkliste fuer den Wartungstermin

Fuer den praktischen Einsatz empfiehlt sich, alle bisher besprochenen Pruefpunkte in eine feste, wiederverwendbare Checkliste zu ueberfuehren, die bei jedem Datenbank-Healthcheck in derselben Reihenfolge durchlaufen wird. Diese Konsistenz ist wichtiger als die Reihenfolge selbst, weil sie Vergleichbarkeit zwischen aufeinanderfolgenden Checks herstellt und schleichende Trends sichtbar macht, die ein einmaliger Snapshot nicht zeigen wuerde.

Die Checkliste sollte pro Punkt einen Zielwert, den zuletzt gemessenen Wert und den Trend seit dem vorherigen Healthcheck dokumentieren. Nur mit dieser historischen Vergleichbarkeit wird aus einem einzelnen Datenbank-Healthcheck ein echtes Frühwarnsystem, das beispielsweise zeigt, dass die Buffer-Pool-Hitrate seit drei aufeinanderfolgenden Checks leicht sinkt, lange bevor sie unter den kritischen Schwellenwert faellt.

10. Zusammenfassung

Ein wirksamer Datenbank-Healthcheck fuer Magento-Shops kombiniert fuenf Kernbereiche: Buffer-Pool-Sizing gegen die tatsaechliche Datenmenge, systematische Slow-Query-Analyse mit pt-query-digest, kontinuierliche Ueberwachung des Replikationslags, regelmaessige Fragmentierungspruefung mit gezieltem OPTIMIZE TABLE und dokumentierte Restore-Tests statt blindem Vertrauen in automatisierte Backups.

Der eigentliche Wert entsteht nicht durch einen einmaligen Check, sondern durch die konsequente Wiederholung mit derselben Checkliste in festen Intervallen. Nur die historische Vergleichbarkeit macht aus einzelnen Messwerten ein Fruehwarnsystem, das schleichende Verschlechterungen erkennt, bevor sie sich als Ausfall im Checkout bemerkbar machen. Ein monatlicher oder quartalsweiser Datenbank-Healthcheck ist damit eine der wirkungsvollsten und zugleich guenstigsten Massnahmen im Betrieb wachsender Magento-Shops.

11. FAQ: Datenbank-Healthcheck fuer Magento-Shops