Fixing High CPU Usage from mds_stores and mdworker (Not a Broken Spotlight)

Seeing mds_stores or mdworker consuming a large share of CPU in Activity Monitor is a completely different situation from Spotlight failing to index at all — this is the opposite problem: Spotlight is actively working, sometimes far more than it should be, and the fix depends entirely on whether that’s a temporary, self-resolving condition or a genuinely stuck reindex loop.

When high mdworker CPU is completely normal

Immediately after a macOS update, a large file copy or restore operation, connecting a new external drive, or first indexing a large removable volume, mdworker processes doing intensive, sustained CPU and disk work for anywhere from several minutes to a few hours is entirely expected — Spotlight is genuinely working through a large volume of new or changed content that needs indexing, and this load resolves on its own once the initial indexing pass completes.

mdutil -s /

Checking indexing status directly, rather than guessing from CPU load alone, tells you whether indexing is actually still in progress (Indexing enabled with active progress) versus already complete — if this reports indexing is complete but mdworker is still consuming significant CPU, that’s a different, less normal situation worth investigating further.

When it’s not normal: the stuck reindex loop

A genuinely problematic pattern is mdworker/mds_stores CPU usage that persists for many hours or days without ever settling down, especially if it seems to restart from the beginning repeatedly rather than making forward progress. This usually indicates Spotlight has hit a specific file or directory it can’t successfully index — a corrupted file, a permissions issue on a specific path, or a genuinely corrupted index — and is retrying that same failure repeatedly rather than moving past it.

Identifying what’s actually being indexed right now

sudo fs_usage -w -f pathname mds_stores mdworker 2>&1 | head -50

Watching the live file activity from the indexing processes themselves shows you exactly what paths they’re currently touching — if this shows the same specific path or file appearing repeatedly rather than a broad, progressing sweep across the filesystem, that’s a strong signal you’ve found the specific stuck point rather than needing to guess at it.

The direct fix: excluding the problematic location, then rebuilding

If a specific path is identified as the stuck point and isn’t something you need indexed anyway, excluding it directly is the most surgical fix:

sudo mdutil -i off /Volumes/problem-volume

or, via System Settings > Siri & Spotlight > Spotlight Privacy, adding the specific problematic folder to the excluded list through the GUI, which most users find more discoverable than the command-line equivalent.

When no specific culprit is identifiable: rebuilding the index from scratch

If you can’t isolate a specific stuck file or path, or excluding the identified culprit doesn’t resolve the underlying high CPU pattern, a full index rebuild is the more thorough fix:

sudo mdutil -E /

The -E flag erases and rebuilds the index for the specified volume entirely from scratch — a more time-consuming fix than excluding a single problem path, since it means re-indexing the entire volume’s contents, but it resolves cases where the index itself has become internally inconsistent in a way that keeps triggering repeated, unproductive reindexing attempts regardless of which specific files are involved.

Confirming the fix actually worked

After either an exclusion or a full rebuild, monitor mdworker/mds_stores CPU usage over the following few hours (allowing time for a legitimate initial reindex pass to complete) — settling back down to near-zero CPU when idle, rather than continuing the same sustained high-usage pattern, confirms the fix actually addressed the underlying cause rather than just temporarily interrupting it.

Why jumping straight to disabling Spotlight entirely is usually the wrong move

Turning off Spotlight system-wide (mdutil -a -i off) does stop the CPU usage, but it also disables a feature deeply integrated into how modern macOS works — Spotlight search itself, but also Quick Look previews, many apps’ internal search functionality, and Time Machine’s file-change tracking all depend on the same indexing infrastructure to varying degrees. Diagnosing and excluding or rebuilding around the actual stuck point is almost always the better trade-off versus losing that functionality entirely just to silence a CPU symptom that has an identifiable, fixable root cause.