Magento 2 Reindex & Index Management: The Complete Guide

What the indexers do

Magento stores catalog data in the EAV model — flexible, but slow to read because a single product spans many tables. Indexers run those joins once and write the result into flat tables the storefront queries directly. Magento Open Source ships nine:

• design_config_grid — design config admin grid
• customer_grid — customer admin grid
• catalog_category_product / catalog_product_category — which products are in which category
• catalogrule_rule / catalogrule_product — catalog price rules
• catalog_product_price — final prices (the heavy one)
• cataloginventory_stock — stock status
• catalogsearch_fulltext — the OpenSearch/Elasticsearch search index

When the underlying data changes, the matching index goes stale and must be rebuilt. How it rebuilds is the index mode.

Update on Save vs Update by Schedule

This is the single most important setting, and 2.4.8 changed its default.

How Update by Schedule works under the hood

This is the MView (materialized view) mechanism, and understanding it makes every “why didn't my change show up” mystery obvious.

1. You save a product. A database trigger writes the product id into a changelog table named after the index, suffixed _cl — for example catalog_product_price_cl.
2. The indexer_update_all_views cron job compares the latest version_id in the _cl table against the value stored in mview_state.
3. If they differ, it reindexes only the changed ids and advances mview_state. The indexer_reindex_all_invalid cron handles indexers explicitly marked invalid.

Two consequences fall out of this: if cron is not running, scheduled indexes never update (see why Magento cron stops firing), and if a changelog table grows huge, reindexing slows down — usually a sign cron has been down for a while.

The CLI you actually need

Check what mode each indexer is in and whether anything is stale:

bin/magento indexer:status
bin/magento indexer:show-mode

Switch modes (do this with the site in maintenance mode and cron paused to avoid deadlocks):

# everything to scheduled (recommended for production)
bin/magento indexer:set-mode schedule

# a single indexer back to realtime
bin/magento indexer:set-mode realtime catalog_product_price

Reindex on demand — all indexers, or just one:

bin/magento indexer:reindex
bin/magento indexer:reindex catalog_product_price cataloginventory_stock

Fixing “Index locked by another reindex process”

This is the most-searched Magento indexing error. It means a previous reindex started, grabbed a lock, and died before releasing it — killed by a timeout, an out-of-memory error, or a deploy. The lock and the indexer's working status never got cleared, so every new reindex refuses to start.

The reliable fix

# 1) reset the stuck indexer state
bin/magento indexer:reset

# 2) clear stale lock files
rm -rf var/locks/*

# 3) reindex, with extra memory if it died on memory before
php -d memory_limit=4G bin/magento indexer:reindex

If a single indexer is stuck rather than all of them, reset just that one: bin/magento indexer:reset catalog_product_price. After the reset its status flips to invalid, which is expected — the next reindex rebuilds it cleanly. I hit exactly this recently on a category indexer after a killed process; reset plus a clean reindex cleared it in seconds.

Writing a custom indexer

When a module needs its own flat data, you register an indexer in indexer.xml and its MView changelog in mview.xml. The action class implements IndexerActionInterface and MviewActionInterface:

<?php
declare(strict_types=1);

namespace Panth\Catalog\Model\Indexer;

use Magento\Framework\Indexer\ActionInterface;
use Magento\Framework\Mview\ActionInterface as MviewActionInterface;

class StockScore implements ActionInterface, MviewActionInterface
{
    public function executeFull(): void
    {
        // rebuild the entire panth_stock_score index table
    }

    public function executeList(array $ids): void
    {
        // reindex only these entity ids (called by Update on Save)
    }

    public function executeRow($id): void
    {
        $this->executeList([(int) $id]);
    }

    public function execute($ids): void
    {
        // called by the MView cron with the changed ids from the _cl table
        $this->executeList(array_map('intval', (array) $ids));
    }
}

The mview.xml subscription tells Magento which table to watch (it creates the _cl changelog and triggers automatically), so your custom index participates in Update by Schedule exactly like the core ones.