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.

When a specific third-party importer plugin is actually crashing

log show --last 1h --predicate 'process == "mdworker_shared"' | grep -i crash

Some sustained high-CPU patterns trace back to a specific, poorly-behaved third-party mdimporter plugin repeatedly crashing on a particular file type and being automatically relaunched by macOS to retry, over and over, without ever succeeding — a subtly different mechanism from a generically “stuck” reindex, but one that produces a very similar sustained-CPU symptom. Filtering the log specifically for mdworker_shared crash events surfaces this pattern directly; if a specific third-party importer is implicated repeatedly, removing the application that installed it (or checking for an update addressing the crash) resolves the underlying cause more permanently than repeatedly excluding whatever files keep triggering it.

Checking whether Time Machine backups are the actual trigger

Because Time Machine and Spotlight indexing interact closely — a new backup volume gets indexed, and file-system change tracking used by both systems overlaps — sustained mdworker activity that correlates specifically with backup windows rather than being constant can point toward that interaction rather than a genuinely broken index. Comparing mdworker activity timing against Time Machine’s own backup schedule (visible in the Time Machine menu bar item’s history) helps rule this specific, more benign explanation in or out before assuming the index itself is corrupted.

Related:

Sources: