Magento Indexing — Indexers, Mview and Reindex Strategies

In this tutorial, you'll learn how Magento indexing transforms raw data into fast storefront queries, the difference between Update on Save and Schedule modes, how Mview tracks changes, and the best strategies for reindexing large catalogs.

What You'll Learn

• What indexing is and why it is essential for storefront performance
• The complete list of indexers and what each one does
• How Update on Save differs from Update by Schedule
• How Mview and database triggers track data changes
• Best practices for reindexing large catalogs without downtime

Why It Matters

Without indexing, every storefront request would scan through raw database tables — a Process that takes seconds instead of milliseconds. Indexing transforms product, price, and inventory data into optimized query tables. Misconfigured indexing is the most common cause of slow category pages and outdated prices.

Real-World Use

An electronics store with 100,000 products imports 5,000 new products every night. With Update on Save mode, each product import takes 3 seconds because of the immediate reindex. The entire import takes over 4 hours. By switching to Update by Schedule mode, the import completes in 10 minutes, and the index runs via cron at 2 AM when traffic is lowest.

Learning Path

flowchart LR
    A[Caching] --> B[Indexing]
    B --> C[Performance Optimization]
    B --> D[Import & Export]
    C --> E[Deployment]
    D --> E
    style B fill:#3b82f6,color:#fff

What Is Indexing?

Indexing is the process of transforming data from its storage format into a format optimized for reading. Think of it like the index at the back of a book — the content is stored in page order, but the index lets you find what you need instantly.

When you save a product in Magento, the raw data goes into EAV tables (entity-attribute-value). But the storefront needs to search by name, filter by price, sort by popularity, and navigate by category. Indexing pre-computes these relationships and stores them in flat tables that the storefront queries directly.

Indexer Lifecycle

1. Data changes (product save, price update, category assign)
2. Change is recorded (directly or via Mview change log)
3. Indexer processes the change and updates index tables
4. Storefront reads from index tables for fast responses

Indexers List

Magento includes several indexers out of the box. Each one handles a specific data domain.

Index Modes

Each indexer can run in one of two modes. Choosing the right mode is critical for performance.

Update on Save

Every time you save an entity, the indexer runs immediately. This means the storefront always shows up-to-date data, but save operations are slower.

Best for: stores with frequent reads and fewer writes, small catalogs, development environments.

# Set a single indexer to real-time mode
bin/magento indexer:set-mode real_time catalog_product_price

Update by Schedule

Changes are recorded but not processed immediately. A cron job runs the indexer at set intervals. Save operations are fast, but storefront data may lag behind by a few minutes.

Best for: production stores with large catalogs, frequent imports, high write volume.

# Set all indexers to schedule mode
bin/magento indexer:set-mode schedule

# Verify the mode
bin/magento indexer:show-mode

Mview — Materialized View

Mview is the mechanism that makes Schedule mode efficient. Instead of scanning all data on every index run, Mview uses database triggers to track only changed rows.

How Mview Works

1. A database trigger fires when a row changes in the source table
2. The trigger inserts the changed row ID into a change log table
3. The indexer reads the change log and processes only those rows
4. The change log is cleared after processing

Change Log Tables

You can find change log tables in your database named like catalog_product_entity_cl or catalog_category_product_index_store_cl. These store the IDs of changed entities since the last index run.

Cron for Indexing

Magento uses cron groups to schedule index processing.

Index Cron Groups

The index cron group runs all indexers set to Schedule mode. Default interval is every minute.

<!-- vendor/magento/module-indexer/etc/cron_groups.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Schedule/etc/cron_groups.xsd">
    <group id="index">
        <schedule_generate_every>15</schedule_generate_every>
        <schedule_ahead_for>20</schedule_ahead_for>
        <schedule_lifetime>15</schedule_lifetime>
        <history_cleanup_every>10</history_cleanup_every>
        <history_success_lifetime>60</history_success_lifetime>
        <history_failure_lifetime>600</history_failure_lifetime>
    </group>
</config>

Check Cron Status

# Check pending index cron jobs
bin/magento cron:run --group=index

# View schedule table in database
SELECT * FROM cron_schedule WHERE job_code LIKE '%index%' ORDER BY scheduled_at DESC LIMIT 10;

Reindex Commands

# Reindex all indexers
bin/magento indexer:reindex

# Reindex a single indexer
bin/magento indexer:reindex catalog_product_price

# Check reindex status
bin/magento indexer:status

A status showing "Ready" means the index is up to date. "Processing" means it is currently running. "Scheduled" means it is pending execution.

Indexer Performance

Large catalogs require careful indexer management to avoid server overload.

Memory Allocation

Processing a catalog with 500,000 products during reindex can use over 2 GB of RAM. Ensure your PHP memory limit is adequate:

; php.ini configuration
memory_limit = 4096M
max_execution_time = 18000

Schedule for Large Catalogs

Always use Schedule mode for production stores with more than 10,000 products. Run reindex during low-traffic hours.

# Set up a cron job for nighttime reindex
0 3 * * * /usr/bin/php /var/www/magento/bin/magento indexer:reindex

Monitor Index Lag

Check if indexing is falling behind by comparing the change log table size against normal levels:

-- MySQL query to check change log size
SELECT TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_NAME LIKE '%_cl'
ORDER BY TABLE_ROWS DESC;

A rapidly growing change log indicates the indexer cannot keep up with the write rate.

Common Mistakes

• Leaving all indexers in Update on Save mode on a production store with a large catalog, causing slow admin save operations and checkout delays
• Running indexer:reindex during business hours on a large catalog, which locks tables and slows the storefront for customers
• Not checking indexer status after an import, leaving customers seeing outdated prices and stock levels
• Ignoring the inventory indexer when using multi-source inventory, resulting in incorrect stock quantities
• Switching to Schedule mode without configuring cron, so indexers never actually run and data becomes increasingly stale

Practice Questions

1. What is the difference between Update on Save and Update by Schedule modes?
2. How does Mview improve indexing performance compared to scanning all data?
3. Why should you check cron_schedule table when indexers seem stuck?

Challenge: Create a monitoring script that checks the status of all indexers every 5 minutes and sends an alert if any indexer shows status other than "Ready" for more than 30 minutes.

FAQ

Mini Project

Create a Shell Script that performs the following: checks all indexer statuses, identifies any indexer not in "Ready" state, runs reindex for those specific indexers, and sends a summary report to an email address. Schedule this script to run nightly via cron.

What's Next

Now that indexing is optimized, continue with Magento Import and Export to learn how to manage product data at scale. Then explore Magento Performance Optimization for CDN, database, and PHP tuning.