Log- und Report-Tabellen in Magento systematisch bereinigen

1. Übersicht: welche Tabellen als Log-Tabellen zählen

In Magento zählen mehrere Log-Tabellen zur Gruppe der protokollierenden, verhaltensbezogenen Tabellen, die bei jedem Seitenaufruf oder jeder Kundeninteraktion Zeilen schreiben. Dazu gehören report_event für allgemeine Events wie Produktansichten und Kategoriebesuche, report_viewed_product_index und report_compared_product_index für aggregierte Produktinteraktionen, customer_visitor und customer_log für Session-Tracking, sowie catalog_compare_item und historisch catalog_compare_item_index für Vergleichslisten.

Diese Log-Tabellen unterscheiden sich fundamental von transaktionalen Tabellen wie sales_order, weil ihr Inhalt für den täglichen Geschäftsbetrieb selten direkt benötigt wird, aber für Reporting, Analytics und Marketing-Auswertungen wertvoll sein kann. Genau diese Doppelrolle macht die Bereinigung heikel: Zu aggressives Löschen zerstört Reporting-Grundlagen, zu zurückhaltendes Löschen führt zu unkontrolliertem Datenbank-Wachstum. Magento liefert für einen Teil dieser Log-Tabellen ein eingebautes Cleanup-System, für andere nicht, was eine differenzierte Strategie erfordert.

Wichtig für die Einordnung: Nicht jede Log-Tabelle wächst gleich schnell. report_event kann bei einem Shop mit hohem Traffic täglich hunderttausende Zeilen erzeugen, während catalog_compare_item deutlich langsamer wächst, aber durch fehlende Bereinigung über Jahre trotzdem relevante Größen erreicht. Diese unterschiedliche Wachstumsdynamik bestimmt, welche Tabelle zuerst adressiert werden sollte.

-- Overview of common Magento log tables and their current size
SELECT table_name,
       table_rows,
       ROUND((data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE table_schema = 'magento'
  AND table_name IN (
    'report_event', 'report_viewed_product_index', 'report_compared_product_index',
    'customer_visitor', 'customer_log', 'catalog_compare_item'
  )
ORDER BY size_mb DESC;

2. report_event im Detail

Die Tabelle report_event ist die zentrale Log-Tabelle für Verhaltensdaten in Magento. Sie protokolliert Ereignisse wie Produktansicht, Warenkorb-Aktionen und Vergleichslisten-Interaktionen mit den Spalten event_type_id, object_id, subject_id, subtype und logged_at. Diese Rohdaten dienen als Grundlage für die aggregierten Reports "Meistangesehene Produkte" und "Meistverglichene Produkte" im Admin-Bereich unter Reports > Products.

Der entscheidende Punkt: Sobald die Aggregation in report_viewed_product_index und report_compared_product_index gelaufen ist, werden die Rohdaten in report_event für die reine Reporting-Funktion nicht mehr benötigt. Genau deshalb bietet Magento ein eingebautes Cleanup für report_event, das die Rohdaten nach einer konfigurierbaren Aufbewahrungsfrist löscht, ohne die aggregierten Auswertungen zu beeinträchtigen. Bei einem Shop mit mehreren zehntausend Seitenaufrufen pro Tag kann report_event ohne aktives Cleanup innerhalb weniger Monate mehrere Millionen Zeilen erreichen.

DESCRIBE report_event;
-- +---------------+------------------+------+-----+---------+----------------+
-- | Field         | Type             | Null | Key | Default | Extra          |
-- +---------------+------------------+------+-----+---------+----------------+
-- | event_id      | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
-- | logged_at     | timestamp        | NO   | MUL | CURRENT |                |
-- | event_type_id | smallint unsigned| NO   | MUL | 0       |                |
-- | object_id     | int(10) unsigned | NO   |     | 0       |                |
-- | subject_id    | int(10) unsigned | NO   |     | 0       |                |
-- | subtype       | smallint unsigned| NO   |     | 0       |                |
-- | store_id      | smallint unsigned| NO   |     | 0       |                |
-- +---------------+------------------+------+-----+---------+----------------+

-- Row count growth rate estimate over the last 7 days
SELECT DATE(logged_at) AS log_date, COUNT(*) AS events
FROM report_event
WHERE logged_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY DATE(logged_at);

3. customer_visitor und customer_log

Die Tabelle customer_visitor protokolliert jede Besuchersitzung, unabhängig davon, ob der Besucher eingeloggt ist oder als Gast browst. Bei modernen Shops mit hoher Bot-Aktivität und wiederkehrenden Crawler-Zugriffen wächst diese Log-Tabelle oft schneller, als es die tatsächliche menschliche Besucherzahl vermuten lässt. Jede Session erzeugt eine Zeile mit visitor_id, session_id, last_visit_at und weiteren Session-Metadaten, die nach Ablauf der Session für den Betrieb keinen Wert mehr haben.

customer_log ergänzt das um Login-bezogene Daten wie letzte Anmeldezeit und Logout-Zeitpunkt für registrierte Kunden. Anders als customer_visitor hat customer_log eine geringere Wachstumsrate, weil nur eingeloggte Kunden Einträge erzeugen, kann aber bei einem Shop mit hoher Wiederkehrer-Rate trotzdem relevant wachsen. Beide Tabellen sind gute Kandidaten für aggressive Bereinigung, weil ihr Wert nach wenigen Tagen praktisch auf null sinkt, es sei denn, ein Custom-Reporting greift explizit auf historische Session-Daten zu.

4. catalog_compare_item: verwaiste Vergleichslisten

Die Tabelle catalog_compare_item speichert, welche Produkte ein Besucher zur Vergleichsliste hinzugefügt hat, verknüpft über visitor_id für Gäste und customer_id für eingeloggte Kunden. Anders als report_event oder customer_visitor hat diese Log-Tabelle standardmäßig kein eingebautes automatisches Cleanup in Magento, was sie zu einem klassischen Kandidaten für verwaistes Wachstum macht.

Ein Gast-Besucher, der drei Produkte vergleicht und die Seite dann verlässt, hinterlässt drei Zeilen in catalog_compare_item, die auf ewig bestehen bleiben, sofern nicht explizit über die zugehörige visitor_id und deren Session-Ablauf in customer_visitor bereinigt wird. Über Jahre akkumulieren sich so Millionen verwaister Vergleichslisten-Einträge, die weder für Reporting noch für den Betrieb einen erkennbaren Nutzen haben, aber bei jeder Abfrage der aktuellen Vergleichsliste eines Besuchers mitgescannt werden.

-- Find catalog_compare_item rows tied to visitor sessions that no longer exist
SELECT COUNT(*) AS orphaned_compare_items
FROM catalog_compare_item cci
LEFT JOIN customer_visitor cv ON cv.visitor_id = cci.visitor_id
WHERE cci.customer_id IS NULL
  AND cv.visitor_id IS NULL;

5. Magentos eingebautes Log Cleaning

Magento bietet unter Stores > Configuration > Advanced > System > Log Cleaning eine zentrale Konfiguration, die für report_event, report_viewed_product_index, report_compared_product_index und verwandte Tabellen die Aufbewahrungsfrist in Tagen (Standard 180) sowie die Ausführungszeit (Standard 2 Uhr nachts) steuert. Ist diese Funktion aktiviert, läuft ein Cron-Job (catalog_product_view_cleanup und verwandte) regelmäßig und löscht Einträge, die älter als die konfigurierte Frist sind.

Der häufigste Fehler in der Praxis ist, dass diese eingebaute Funktion in der Admin-Konfiguration schlicht deaktiviert ist, oft, weil sie bei der initialen Shop-Einrichtung nie explizit aktiviert wurde, geprüft zum Beispiel mit bin/magento config:show system/log/enabled. Ein zweiter häufiger Fehler ist eine zu lange Aufbewahrungsfrist, etwa 365 Tage, obwohl die aggregierten Reports auf Basis von 90 Tagen ausreichend aussagekräftig wären. Die Aktivierung und richtige Konfiguration dieses eingebauten Log Cleanings ist der wirksamste erste Schritt gegen wachsende Log-Tabellen in Magento.

6. bin/magento-CLI-Befehle für Log Cleaning

Neben der Cron-gesteuerten automatischen Bereinigung bietet Magento den CLI-Befehl bin/magento log:clean, der die konfigurierte Log-Bereinigung manuell und sofort auslöst, unabhängig vom nächtlichen Cron-Zeitpunkt. Das ist besonders nützlich nach der Erstaktivierung des Log Cleanings, wenn bereits Monate an unbereinigten Daten in report_event liegen und man nicht bis zum nächsten nächtlichen Lauf warten möchte.

Der Befehl akzeptiert eine optionale Anzahl von Tagen als Parameter, um die Aufbewahrungsfrist für den einzelnen Aufruf zu überschreiben, ohne die dauerhafte Konfiguration zu ändern. Das ist praktisch für einen einmaligen, aggressiveren Cleanup bei einer bereits stark aufgeblähten Log-Tabelle, gefolgt von einer moderateren dauerhaften Einstellung für den Regelbetrieb.

# Enable log cleaning and set retention to 90 days
bin/magento config:set system/log/enabled 1
bin/magento config:set system/log/save_days 90

# Trigger log cleanup immediately using the configured retention period
bin/magento log:clean

# Override retention for this single run (e.g. aggressive one-time cleanup)
bin/magento log:clean --days 30

# Verify the effect afterwards
bin/magento cache:flush

7. Custom-Cleanup-Skripte für ungeschützte Tabellen

Für Log-Tabellen ohne eingebautes Cleanup wie catalog_compare_item und teilweise customer_visitor in älteren Magento-Versionen ist ein eigenes Cleanup-Skript notwendig. Ein solches Skript sollte in klar abgrenzbaren, batched Schritten arbeiten: zuerst abgelaufene customer_visitor-Sessions identifizieren, dann darauf basierend verwaiste catalog_compare_item-Zeilen entfernen, jeweils mit einer Obergrenze pro Durchlauf, um lange Locks zu vermeiden.

Wichtig bei Custom-Skripten ist, die Löschbedingung präzise zu formulieren, damit keine aktiven Vergleichslisten eingeloggter Kunden versehentlich gelöscht werden. Ein Filter auf customer_id IS NULL stellt sicher, dass nur Gast-Vergleichslisten betroffen sind, während eingeloggte Kunden ihre Vergleichsliste über Sessions hinweg behalten dürfen.

-- Custom cleanup for catalog_compare_item without built-in Magento support
-- Step 1: remove compare items tied to expired guest visitor sessions
DELETE cci FROM catalog_compare_item cci
LEFT JOIN customer_visitor cv ON cv.visitor_id = cci.visitor_id
WHERE cci.customer_id IS NULL
  AND cv.visitor_id IS NULL
LIMIT 5000;

-- Step 2: remove stale customer_visitor rows older than 30 days
DELETE FROM customer_visitor
WHERE last_visit_at < DATE_SUB(NOW(), INTERVAL 30 DAY)
LIMIT 5000;

8. Performance-Effekt auf Reports und Backups

Aufgeblähte Log-Tabellen wirken sich messbar auf die Performance mehrerer Bereiche aus. Im Admin-Bereich verlangsamen sich die Reports "Meistangesehene Produkte" und "Meistverglichene Produkte", weil die zugrunde liegende Aggregation über eine größere Rohdatenmenge in report_event läuft. Bei Backups verlängert sich die mysqldump-Zeit proportional zur Gesamtgröße, und stark gewachsene Log-Tabellen können bei einem Shop ohne konsequentes Cleanup einen überproportionalen Anteil der Gesamtdatenbankgröße ausmachen.

Ein weniger offensichtlicher Effekt betrifft die tägliche Admin-Nutzung: Abfragen, die customer_visitor oder catalog_compare_item joinen, etwa um die aktuelle Vergleichsliste eines Besuchers anzuzeigen, werden bei Millionen verwaister Zeilen langsamer, selbst wenn die relevante Ergebnismenge klein ist, weil MySQL mehr Indexeinträge durchsuchen muss. Regelmäßiges Bereinigen dieser Log-Tabellen ist damit keine reine Aufräumaktion, sondern eine direkte Performance-Maßnahme.

9. Automatisierung: Cron-Einrichtung und Monitoring

Die nachhaltigste Lösung gegen wachsende Log-Tabellen ist die Kombination aus aktiviertem eingebautem Log Cleaning für die dafür vorgesehenen Tabellen und einem eigenen Cron-Job für Tabellen ohne eingebaute Unterstützung. Dieser eigene Cron-Job lässt sich über eine crontab.xml in einem Custom-Modul registrieren oder als System-Cron-Eintrag außerhalb von Magento einrichten, wichtig ist nur, dass er regelmäßig und außerhalb der Stoßzeiten läuft.

Ergänzend sollte ein Monitoring die Wirksamkeit der Bereinigung überprüfen, indem es die Größe der wichtigsten Log-Tabellen wöchentlich protokolliert und bei unerwartetem Wachstum alarmiert. Das deckt auf, wenn das eingebaute Log Cleaning nach einem Update oder einer Konfigurationsänderung unbemerkt deaktiviert wurde, bevor die Tabelle wieder unkontrolliert wächst.

Vergleich: Log-Tabellen und ihre Bereinigungsoptionen

10. Zusammenfassung

Log-Tabellen wie report_event, customer_visitor und catalog_compare_item protokollieren Besucherverhalten und wachsen bei jedem Seitenaufruf, oft schneller als jede andere Tabellengruppe in einem Magento-Shop. Magento liefert für einen Teil dieser Tabellen ein eingebautes Log Cleaning über Stores > Configuration > Advanced > System, das häufig nicht aktiviert oder mit einer zu langen Aufbewahrungsfrist konfiguriert ist.

Für Log-Tabellen ohne eingebaute Unterstützung wie catalog_compare_item ist ein eigenes, batched Cleanup-Skript notwendig, das verwaiste Einträge präzise identifiziert, ohne aktive Kundendaten zu gefährden. Die Kombination aus aktiviertem Log Cleaning, bin/magento log:clean für sofortige Bereinigung und eigenen Skripten für ungeschützte Tabellen hält die Datenbank schlank und verbessert messbar die Performance von Reports, Backups und alltäglichen Admin-Abfragen.

11. FAQ: Log- und Report-Tabellen bereinigen