Catalog Price Rule Indexer im Detail: Wie automatische Rabatte berechnet werden

1. Index versus Runtime: der fundamentale Unterschied zu Cart Price Rules

Cart Price Rules, also Warenkorb-Preisregeln mit oder ohne Gutscheincode, werden bei jeder Warenkorb-Berechnung live ausgewertet: Der Validator prüft die Bedingungen jeder aktiven Regel gegen den aktuellen Warenkorbinhalt und wendet passende Aktionen in Echtzeit an. Das ist möglich, weil ein Warenkorb naturgemäß klein ist, meist wenige bis einige Dutzend Positionen, sodass die Regelauswertung pro Request vertretbar bleibt.

Catalog Price Rules dagegen betreffen potenziell den gesamten Produktkatalog gleichzeitig, sichtbar auf jeder Kategorieseite, jeder Produktseite und in jedem Preisfilter der Layered Navigation. Eine Live-Auswertung sämtlicher aktiven Regeln gegen jedes einzelne angezeigte Produkt bei jedem Seitenaufruf wäre bei tausenden Produkten schlicht nicht performant genug, weshalb Magento hier bewusst auf Vorberechnung statt Runtime-Auswertung setzt.

2. Wie der catalogrule_rule-Indexer arbeitet

Der Indexer mit der ID catalogrule_rule iteriert über alle aktiven Catalog Price Rules und ermittelt für jede Regel die zugehörigen Produkte über deren Bedingungen, etwa Kategoriezugehörigkeit oder Attributwerte. Für jede Kombination aus Produkt, Kundengruppe, Website und Gültigkeitszeitraum berechnet der Indexer den resultierenden Regelpreis und schreibt das Ergebnis in die Tabelle catalogrule_product_price, versehen mit einem Gültigkeits-Zeitraum, innerhalb dessen der berechnete Preis unverändert gilt.

Ändert sich innerhalb des Gültigkeitszeitraums einer Regel nichts an den beteiligten Produkten oder Bedingungen, bleibt der vorberechnete Zeitraum in einer einzigen Zeile bestehen. Ändert sich hingegen etwa der Prozentsatz des Rabatts zu einem bestimmten Datum durch eine zweite, zeitlich versetzte Regel auf dasselbe Produkt, entstehen mehrere Zeilen mit jeweils eigenem Gültigkeitsfenster, wodurch die Zeilenanzahl in catalogrule_product_price mit der Anzahl zeitlich gestaffelter Regeländerungen pro Produkt wächst.

# Status und Modus des Catalog-Rule-Indexers prüfen
bin/magento indexer:status catalogrule_rule
bin/magento indexer:show-mode catalogrule_rule

3. Wie die Preisanzeige die vorberechneten Regelpreise nutzt

Die eigentliche Preisanzeige greift nicht direkt auf catalogrule_product_price zu, sondern über den Preisindexer catalog_product_price, der beim Aufbau der finalen Preisindex-Tabellen catalog_product_index_price die vorberechneten Regelpreise für das jeweils aktuelle Datum berücksichtigt und mit regulären Preisen sowie eventuellen Sonderpreisen vergleicht, um den niedrigsten anzuzeigenden Preis zu bestimmen.

Diese Verkettung zweier Indexer bedeutet in der Praxis, dass eine neu angelegte oder geänderte Catalog Price Rule erst nach einem vollständigen Durchlauf von catalogrule_rule und anschließend catalog_product_price tatsächlich im Frontend sichtbar wird. Läuft nur der eine Indexer, aber nicht der andere, zeigt der Katalog trotz korrekt berechneter Regelpreise weiterhin die alten Preise an, ein häufiger Verwirrungspunkt bei der Fehlersuche nach einer Regeländerung.

4. Performance-Probleme bei vielen aktiven Regeln und großem Katalog

Die Laufzeit des catalogrule_rule-Indexers wächst nicht linear, sondern kombinatorisch: Jede zusätzliche aktive Regel multipliziert sich mit der Anzahl betroffener Produkte, der Anzahl Kundengruppen, der Anzahl Websites und der Anzahl zeitlicher Gültigkeitsabschnitte. Bei einem Katalog mit mehreren Zehntausend Produkten und einer zweistelligen Zahl gleichzeitig aktiver, sich überschneidender Regeln kann ein voller Reindex-Lauf spürbar lange dauern und währenddessen erhebliche Datenbanklast erzeugen.

Besonders kritisch wirken sich Regeln mit unbegrenzten oder sehr weit in die Zukunft reichenden Gültigkeitszeiträumen aus, weil sie die Berechnung zeitlicher Abschnitte unnötig aufblähen, sowie breit gefasste Bedingungen, die praktisch den gesamten Katalog statt einer klar abgegrenzten Produktmenge treffen. Eine regelmäßige Durchsicht abgelaufener oder überflüssig gewordener Regeln, die aus Bequemlichkeit einfach deaktiviert statt gelöscht wurden, reduziert die Indexer-Last spürbar, weil deaktivierte Regeln zwar nicht neu berechnet, aber ihre historischen Zeilen in der Tabelle trotzdem mitgeführt werden.

5. Reindex-Modus strategisch wählen: Schedule versus Save

Im Modus Update on Save wird bei jeder Regeländerung sofort ein vollständiger Reindex angestoßen, was im Admin-Betrieb bei häufigen Regeländerungen zu spürbaren Wartezeiten führt, weil der Speichervorgang blockiert, bis der Indexer durchgelaufen ist. Für Shops mit häufig wechselnden Kampagnen ist Update by Schedule deutlich verträglicher, da die eigentliche Neuberechnung asynchron über den Cron-Job indexer_reindex_all_invalid beziehungsweise die Mview-Changelog-Verarbeitung läuft.

Wichtig ist dabei, den Cron-Takt realistisch auf die tatsächliche Änderungsfrequenz der Regeln abzustimmen: Ein zu selten laufender Reindex-Cron führt dazu, dass neue Rabattaktionen verspätet im Frontend erscheinen, während ein zu häufig laufender Cron unnötig Systemressourcen bindet, ohne dass sich zwischen zwei Läufen überhaupt etwas an den Regeln geändert hätte.

# Catalog-Rule-Indexer gezielt auf Schedule-Modus umstellen
bin/magento indexer:set-mode schedule catalogrule_rule catalog_product_price

6. Gezielte Reindex-Strategien statt pauschalem Voll-Reindex

Statt bei jeder kleinen Regeländerung reflexartig einen vollständigen Reindex über den gesamten Katalog anzustoßen, lohnt sich eine bewusste Trennung zwischen Regeln, die wirklich den gesamten Katalog betreffen, etwa eine websiteweite Rabattaktion, und Regeln, die nur eine klar abgegrenzte Produktmenge treffen, etwa eine einzelne Kategorie. Für letztere lässt sich über gezielte Bedingungen die Trefferzahl der Regel bewusst klein halten, was die kombinatorische Last des Indexers direkt reduziert.

Bei geplanten, im Voraus bekannten Kampagnen mit fixem Start- und Enddatum empfiehlt sich außerdem, die Regel rechtzeitig vor dem eigentlichen Kampagnenstart anzulegen und den Indexer außerhalb der Stoßzeiten einmalig vollständig durchlaufen zu lassen, statt auf den regulären Cron-Takt während des eigentlichen Kampagnenstarts zu vertrauen, wenn ohnehin erhöhte Systemlast durch mehr Traffic zu erwarten ist.

7. Grenzen des Partial Reindex bei Catalog Price Rules

Anders als etwa der Preisindexer für reguläre Produktpreisänderungen, der über Mview-Changelogs gezielt nur betroffene Produkte nachträgt, arbeitet der catalogrule_rule-Indexer bei einer Regeländerung faktisch immer regelbezogen vollständig: Ändert sich eine einzelne Regel, werden alle von dieser Regel betroffenen Produkte über den kompletten Gültigkeitszeitraum neu berechnet, nicht nur die seit dem letzten Lauf tatsächlich geänderten.

Diese Einschränkung lässt sich nicht durch Konfiguration umgehen, sondern nur durch eine bewusste Reduktion des Regel-Scopes selbst: Je kleiner die von einer einzelnen Regel betroffene Produktmenge, desto günstiger fällt jede Neuberechnung dieser Regel aus. Bei Regeln, die ohnehin nahezu den gesamten Katalog betreffen, bleibt oft nur die Möglichkeit, deren Änderungen bewusst zu bündeln und außerhalb der Hauptgeschäftszeiten einzuspielen, statt mehrere kleine Anpassungen über den Tag verteilt vorzunehmen.

8. Indexer-Laufzeit überwachen und Engpässe früh erkennen

Ein sinnvolles Monitoring erfasst die Laufzeit jedes catalogrule_rule-Durchlaufs über die Zeit und schlägt Alarm, sobald sich ein deutlicher Anstieg gegenüber dem historischen Durchschnitt zeigt, weil ein solcher Anstieg fast immer auf eine neu hinzugekommene, zu breit gefasste Regel oder eine unerwartet stark gewachsene Produktmenge hindeutet, lange bevor Kunden verspätete Preisaktualisierungen im Frontend bemerken.

Ergänzend hilft eine regelmäßige Kontrolle der Zeilenanzahl in catalogrule_product_price, da ein unerwartet sprunghafter Anstieg dieser Tabelle meist direkt mit einer neuen Regel korreliert, deren Bedingungen unbeabsichtigt viel breiter greifen als eigentlich beabsichtigt, etwa durch eine versehentlich zu allgemein formulierte Attributbedingung.

9. Indexer-Bausteine im Überblick

Die folgende Tabelle fasst die zentralen Bausteine des Catalog-Price-Rule-Indexings mit ihrer jeweiligen Rolle zusammen.

10. Zusammenfassung

11. FAQ: Catalog-Price-Rule-Indexer: Das Wichtigste auf einen Blick