Magento 2 판매 주문 실적: 그리드 인덱싱, 주문 로딩 및 대량 작업

Most Magento 2 performance articles focus on the storefront — caching, Varnish, product pages. But there’s a second performance front that hurts just as much: the backend order management. When your shop grows past a few thousand orders, the sales order grid slows down, the order view page takes seconds to load, exports time out, and your customer service team starts waiting on screens instead of helping customers.

The frustrating part? This degradation is gradual. It sneaks up on you. One day the grid loads in 300ms, a year later it takes 8 seconds — and nobody knows why.

This guide breaks down the three biggest order-management bottlenecks in Magento 2, and what to do about each one.

How Magento 2 Stores and Loads Orders

Before optimizing, it helps to understand the sales data model. Magento 2 spreads every order across many tables:

• sales_order — the order base record (customer, totals, status)
• sales_order_item — ordered products
• sales_order_address — billing and shipping addresses
• sales_order_payment — payment details
• sales_order_status_history — status comments and history
• sales_order_grid — a denormalized table built for fast grid rendering
• sales_invoice, sales_shipment, sales_creditmemo — their grids and items

The key table is sales_order_grid. Since Magento 2.1 it’s maintained by a dedicated indexer (sales_grid_order_indexer) that copies the most relevant order fields into a flat, query-friendly structure. The grid UI components, the order export, and many admin listings all query this table — not sales_order directly.

That design is smart in theory. In practice, it’s where most order-management performance problems start.

1. The Sales Grid Indexer Is Your First Bottleneck

The sales_grid_order_indexer (and its siblings for invoices, shipments and credit memos) runs every time an order changes: new order, status update, comment added, invoice created. On a busy shop that’s thousands of reindex operations per day.

Three things typically go wrong:

The indexer runs synchronously. By default the indexer is set to “Update on Save”, meaning every order save triggers a full grid update inline — blocking the checkout queue and admin operations. Fix: switch all sales grid indexers to Update by Schedule:

bin/magento indexer:set-mode schedule sales_grid_order_indexer
bin/magento indexer:set-mode schedule sales_grid_invoice_indexer
bin/magento indexer:set-mode schedule sales_grid_shipment_indexer
bin/magento indexer:set-mode schedule sales_grid_creditmemo_indexer

Enter fullscreen mode Exit fullscreen mode

The cron schedule is too aggressive or too sparse. If you set the schedule to run every minute, each run still processes the delta since the last run. If it runs hourly on a high-volume shop, the grid is constantly stale and queries hit partially updated rows. Measure the actual indexer duration:

bin/magento indexer:show-mode
bin/magento indexer:status
# Or via SQL: check the last run duration
SELECT * FROM mview_state WHERE view_id IN ('sales_order_grid', 'sales_grid_invoice_grid', ...);

Enter fullscreen mode Exit fullscreen mode

A healthy setup indexes every 5–15 minutes and finishes in seconds. If a run takes minutes, see section 2.

Every comment creates a grid update. Status history comments trigger grid reindexes too. If your ERP or integration posts dozens of comment updates per order, that’s dozens of grid refreshes. Check your sales_order_status_history growth rate — if comments spam is high, consider whether every comment truly needs to mutate the grid, or whether your integration can batch its updates.

2. Grid Bloat, Orphans and Table Maintenance

Over months, the sales_order_grid table accumulates orphaned rows: orders are deleted from sales_order (mass delete, GDPR erasure, test cleanup) but rows linger in the grid. Every orphan is dead weight in every grid query, and the grid indexer keeps trying to sync them.

A quick diagnostic:

-- Orphaned grid rows
SELECT COUNT(*) FROM sales_order_grid g
LEFT JOIN sales_order o ON o.entity_id = g.entity_id
WHERE o.entity_id IS NULL;

Enter fullscreen mode Exit fullscreen mode

If that returns thousands of rows, clean them up:

# With magerun2 — the safe way
n98-magerun2 index:reindex sales_grid_order_indexer:full --force

Enter fullscreen mode Exit fullscreen mode

Or manually, after a backup:

DELETE g FROM sales_order_grid g
LEFT JOIN sales_order o ON o.entity_id = g.entity_id
WHERE o.entity_id IS NULL;

Enter fullscreen mode Exit fullscreen mode

For shops with millions of orders, think about archiving instead of deleting. Magento ships with a built-in Sales Archive feature (Stores → Configuration → Sales → Sales Archive) that moves old orders to sales_order_archive tables and removes them from the live grid. My recommended threshold: archive orders older than 12–18 months — customer service rarely needs them in the live grid, and order data remains fully accessible via the archive UI.

If you’re on MySQL 8 / MariaDB and run into index rebuild pain on multi-million-row grids, consider table partitioning on created_at (monthly or quarterly partitions) so the indexer and grid queries only touch recent partitions. This is a bigger change — test it thoroughly on a clone first — but it’s the single most effective fix for truly huge order tables.

3. N+1 Order Loading — the Hidden Admin Killer

The grid being slow is one thing. The order view page being slow is another — and it’s almost always N+1 queries.

The classic symptom: opening a single order takes 3–6 seconds even though the grid was instant. What’s happening under the hood:

1. The order is loaded via the repository or load() with its related entities
2. Then each block does its own lazy loading: items, addresses, payment info, status history, invoices, shipments, credit memos, custom extension attributes from third-party modules
3. Every lazy load fires new queries — and some extension attributes trigger nested loads per item

Third-party modules are the usual suspects: ERP sync modules, order comments modules, invoice PDF modules that attach attributes to every order load. A quick way to find them is to enable SQL logging or profiler output on the admin order page and count the queries — if one order view fires 200+ queries, you have a problem.

Standard countermeasures:

• Batch-load instead of loop-load wherever your code touches orders:

  // Bad: N+1 — a query per order
  foreach ($orderIds as $orderId) {
      $order = $this->orderRepository->get($orderId);
      $total += $order->getGrandTotal();
  }

  // Good: one query for all orders, one for all items
  $orderCollection = $this->orderCollectionFactory->create();
  $orderCollection->addFieldToFilter('entity_id', ['in' => $orderIds]);
  $orderCollection->getSelect()->joinLeft(
      ['soi' => $orderCollection->getTable('sales_order_item')],
      'soi.order_id = main_table.entity_id',
      ['items_grand_total' => 'SUM(soi.row_total_incl_tax)']
  );
  $orderCollection->getSelect()->group('main_table.entity_id');

Enter fullscreen mode Exit fullscreen mode

• Disable unused extension attributes on the order entity (extension_attributes.xml) so they’re not loaded on every order load.
• Prevent lazy-loading loops in your own modules: if you need invoices for an order, fetch them once with a collection and map them by order_id, never per-order.

4. Bulk Operations: Exports, Mass Actions and ERP Sync

Order export, mass status changes, and ERP polling are the third performance front. These jobs look like they run “in the background”, but if they’re implemented as synchronous PHP loops, they’re hammering your database, consuming PHP-FPM workers, and slowing down everything else — including the storefront.

The correct pattern is always the same:

Move heavy work to a message queue. Magento 2 has built-in support via RabbitMQ or the database message queue. Wrap bulk order operations in async consumers:

<!-- etc/queue_consumer.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/consumer.xsd">
    <consumer name="order.export.batch"
              queue="order.export.queue"
              handler="Vendor\Module\Model\OrderExportConsumer::process"
              connection="amqp"/>
</config>

Enter fullscreen mode Exit fullscreen mode

Then process batches with configurable size, and throttle:

public function process($message): void
{
    $batchSize = 500; // tune based on your DB
    $orderIds = json_decode($message->getBody(), true);

    foreach (array_chunk($orderIds, $batchSize) as $chunk) {
        $orders = $this->loadOrders($chunk); // one collection query
        foreach ($orders as $order) {
            $this->exportOne($order);
        }
        // give the DB a breath between chunks
        usleep(100_000);
    }
}

Enter fullscreen mode Exit fullscreen mode

Two more wins for bulk operations:

• Chunking + temp tables for exports. For very large exports, write the selected IDs to a temp table first, then stream pages of 1000 rows — instead of one giant IN (...) with 100k IDs that blows up the query planner.
• Indexes that match your ERP queries. Your ERP integration probably polls orders by status and date. Make sure these queries are indexed:

ALTER TABLE sales_order
  ADD KEY `IDX_STATUS_CREATED_AT` (`status`, `created_at`);
ALTER TABLE sales_order
  ADD KEY `IDX_CUSTOMER_ID_CREATED_AT` (`customer_id`, `created_at`);

Enter fullscreen mode Exit fullscreen mode

A missing index on status + created_at is one of the most common reasons ERP polls grind the database — the query scans the whole order table on every sync cycle.

5. Optimizing the Admin Grid Itself

The order grid UI component can be optimized too:

• Only enable columns you need. Every visible column adds a query fragment. Disable rarely-used columns (configurable via di.xml or the sales_order_grid UI component XML) to keep the grid SELECT slim.
• Filter on indexed columns only. Custom grid columns that filter on non-indexed fields force full scans of sales_order_grid. If you must filter on a field, add the corresponding index.
• Cap the grid page size. Set pageSize to a sane default (20–25) instead of letting users request 100-row pages on a 2M-row grid.
• Use the built-in sorting on indexed columns (created_at, increment_id, status) — sorting on arbitrary columns costs an extra filesort.

6. Monitoring so It Never Sneaks Up Again

Finally, set up basic monitoring around order management so the next regression is caught early:

• Track grid indexer duration (mview_state timestamps) — alert if a run exceeds your baseline.
• Watch sales_order_grid row count vs sales_order row count for orphan growth.
• Enable the MySQL slow query log on a staging or low-traffic replica and scan for sales_order / sales_order_grid queries with high execution time.
• Count queries on the order view page weekly — a regression from 80 to 300 queries per page load is an early warning sign of a badly written extension attribute or module.

The Checklist

To recap, this is your order-management performance playbook:

1. Set all four sales grid indexers to Update by Schedule (5–15 min interval)
2. Clean orphaned grid rows quarterly; archive orders older than 12–18 months
3. Partition huge order tables on created_at if you’re past millions of rows
4. Kill N+1 order loading — batch collections, prune extension attributes
5. Move exports, mass actions and ERP sync to message queues with chunked processing
6. Index status + created_at and customer_id + created_at for integration queries
7. Keep the admin grid lean: fewer columns, indexed filters, capped page size
8. Monitor indexer duration, grid growth and order-view query counts

Order management performance doesn’t get the glory of Varnish or Redis tuning, but your customer service team, your ERP integration and your sanity will thank you. Fix the grid indexer, kill the N+1s, and queue the bulk work — that’s 80% of the problem, solved.