Magento 2 indexering uitgelegd — flat tables en materialized views

80% van de Magento 2 performance-klachten die wij binnenkrijgen zijn te herleiden tot één oorzaak: indexering die niet goed is geconfigureerd. Een webshop die 8 seconden doet over een categoriepagina heeft geen server-probleem. Hij heeft een indexeringsprobleem.

Dit artikel legt uit hoe Magento's indexeringssysteem werkt, wat het verschil is tussen flat tables en materialized views, en wanneer je welke indexer-modus gebruikt.

Wat je leert in dit artikel

• Hoe Magento's indexeringssysteem werkt
• Flat tables: wanneer aan, wanneer uit
• Realtime vs. schedule indexering: de afweging
• Troubleshooting van vastgelopen indexers
• Performance-impact per indexer

Waarom Magento indexering nodig heeft

Magento slaat productdata op in een EAV-structuur (Entity-Attribute-Value). Een product met 50 attributen levert 50 rijen op in catalog_product_entity_varchar, catalog_product_entity_int, enzovoort. Een simpele productpagina vereist dan tientallen JOIN-queries.

Dat is te traag voor frontend gebruik. Indexering lost dit op door de data te denormaliseren naar flat tables — tabellen waarbij één rij één product vertegenwoordigt, met alle attributen als kolommen.

-- Zonder indexering: meerdere queries met JOINs
SELECT e.entity_id, varchar_attr.value as name, int_attr.value as status
FROM catalog_product_entity e
JOIN catalog_product_entity_varchar varchar_attr
    ON e.entity_id = varchar_attr.entity_id
    AND varchar_attr.attribute_id = 73
JOIN catalog_product_entity_int int_attr
    ON e.entity_id = int_attr.entity_id
    AND int_attr.attribute_id = 97
WHERE e.entity_id = 123;

-- Met flat table: één simpele query
SELECT entity_id, name, status
FROM catalog_product_flat_1
WHERE entity_id = 123;

De flat table-aanpak is 10-50x sneller bij het lezen. Het nadeel: je moet de flat tables up-to-date houden wanneer data verandert.

De indexers in Magento 2

Magento 2 heeft de volgende standaard indexers:

Bekijk de huidige status:

bin/magento indexer:status

Output:

Design Config Grid:                                | Ready | Update by Schedule
Customer Grid:                                     | Ready | Update by Schedule
Category Products:                                 | Reindex required | Update by Schedule
Product Categories:                                | Reindex required | Update on Save
Product Price:                                     | Ready | Update by Schedule
Product EAV:                                       | Ready | Update on Save

Flat tables: aan of uit?

De flat catalog-functie is controversieel in de Magento-community. Hier is de feitelijke afweging:

Flat tables inschakelen heeft zin als:

• Je meer dan 5.000 producten hebt
• Je attributen relatief stabiel zijn
• Je voornamelijk leest (frontend requests) en weinig schrijft

Flat tables uitschakelen heeft zin als:

• Je minder dan 5.000 producten hebt
• Je regelmatig attributen aanpast
• Je Hyva Theme gebruikt (Hyva gebruikt GraphQL, geen flat tables)
• Je een headless frontend hebt

Inschakelen via admin of CLI:

# Inschakelen
bin/magento config:set catalog/frontend/flat_catalog_category 1
bin/magento config:set catalog/frontend/flat_catalog_product 1

# Vervolgens opnieuw indexeren
bin/magento indexer:reindex catalog_category_flat catalog_product_flat

Realtime vs. schedule: de afweging

Elke indexer kan in twee modi draaien:

Update on Save — De indexer draait onmiddellijk wanneer je een product opslaat in de admin. De data is altijd actueel, maar het opslaan duurt langer. Bij een catalogus van 100.000+ producten kan een simpele categorie-update minuten duren.

Update by Schedule — De indexer registreert dat er iets veranderd is en verwerkt de wijzigingen bij de volgende cron-run. Het opslaan in admin gaat snel, maar de frontend ziet de wijziging pas na de volgende cron-run (standaard elke minuut).

# Alle indexers op schedule zetten
bin/magento indexer:set-mode schedule

# Of individueel
bin/magento indexer:set-mode schedule catalog_product_price
bin/magento indexer:set-mode schedule catalogsearch_fulltext

# Huidige modus bekijken
bin/magento indexer:show-mode

Voor productie-omgevingen met meer dan 10.000 producten adviseren wij altijd schedule voor alle zware indexers. De admin-gebruiker merkt nauwelijks het verschil, maar de server wel.

Hoe schedule-indexering werkt

Wanneer je een product opslaat met schedule-modus actief, schrijft Magento een rij naar mview_state en de bijbehorende changelog-tabel (bijv. catalog_product_cl). De cron-job indexer_reindex_all_invalid leest deze changelogs en verwerkt alleen de gewijzigde entiteiten.

-- Bekijk de changelog-tabel voor productprijzen
SELECT * FROM catalog_product_price_cl ORDER BY version_id DESC LIMIT 10;

-- Bekijk welke versies verwerkt zijn
SELECT * FROM mview_state WHERE view_id = 'catalog_product_price';

Dit is de reden waarom schedule-indexering zo efficiënt is: in plaats van de hele catalogus opnieuw te indexeren, verwerkt hij alleen wat veranderd is.

Troubleshooting: vastgelopen indexers

Een indexer kan in de staat Processing blijven hangen. Dit gebeurt wanneer een eerdere indexering is gecrasht zonder de vergrendeling vrij te geven.

# Status controleren
bin/magento indexer:status

# Alle indexers opnieuw markeren als geldig
bin/magento indexer:reset

# Specifieke indexer resetten
bin/magento indexer:reset catalog_product_price

# Handmatig opnieuw indexeren
bin/magento indexer:reindex catalog_product_price

Als een indexer regelmatig vastloopt, controleer dan de MySQL slow query log en de Magento var/log/ logs:

# Magento indexer-logs bekijken
tail -f var/log/system.log | grep -i index

# MySQL processlist bekijken op lange queries
mysql -u magento -p magento -e "SHOW PROCESSLIST;"

Performance-impact: cijfers

Wij hebben gemeten op een webshop met 45.000 producten:

De eerste drie scenario's zijn servertijd zonder caching. Het vierde scenario laat zien wat er mogelijk is met de volledige optimalisatiestack.

Cron-configuratie voor indexering

De cron-jobs voor indexering moeten correct ingesteld zijn. Controleer dit:

# Magento cron instellen
bin/magento cron:install

# Cron handmatig uitvoeren (voor testen)
bin/magento cron:run --group index

# Cron-status bekijken
bin/magento cron:status

In de server crontab moet dit staan:

* * * * * /usr/bin/php /var/www/magento/bin/magento cron:run >> /var/www/magento/var/log/magento.cron.log 2>&1

Zonder een werkende cron draaien schedule-indexers nooit. Dit is een van de meest voorkomende oorzaken van verouderde data in productie.

Veelgemaakte fouten

1. Alle indexers op realtime zetten — Bij grote catalogi maakt dit elke admin-opslag traag. Zet de zware indexers op schedule.
2. Flat tables aanzetten bij Hyva — Hyva gebruikt GraphQL en geen flat tables. Aanzetten heeft dan geen nut maar kost wel reindex-tijd.
3. Cron vergeten na deployment — Na een setup:upgrade of server-migratie staat de cron soms niet meer correct in. Altijd controleren met bin/magento cron:status.

Conclusie

Magento's indexeringssysteem is krachtig maar vereist bewuste keuzes. Flat tables zijn niet altijd de oplossing, en realtime indexering is zelden de juiste keuze voor grote catalogi.

De praktische aanbeveling: zet alle zware indexers op schedule, controleer of cron correct draait en meet de impact. In combinatie met Redis full-page caching is Magento heel snel.

Meer weten over database-optimalisatie? Lees Magento 2 database-optimalisatie. Bekijk ook onze Magento 2 diensten voor een volledig overzicht. De Adobe Commerce indexering documentatie bevat de volledige referentie.

Hebben jullie performance-problemen met Magento 2? Neem contact op voor een concrete analyse.