<!-- llms-explorer concept facts · https://llms-explorer.com/tree/reading-sharded-explain-output-shards-single-shard-shard-merge/ · pack 2026-10-23 · ~1164 tokens -->

# Reading sharded explain output (shards, SINGLE_SHARD, SHARD_MERGE)

> Source-anchored research for Reading sharded explain output (shards, SINGLE_SHARD, SHARD_MERGE). Run status: COMPLETED.

Parent: [Covered queries on sharded collections](https://llms-explorer.com/tree/covered-queries-on-sharded-collections/) · 4 facets · 10 facts · page: https://llms-explorer.com/tree/reading-sharded-explain-output-shards-single-shard-shard-merge/

## Structure and components

- For a sharded collection, MongoDB v8.3 places a router-level stage and a shards array under queryPlanner.winningPlan. Each shards entry identifies an accessed shard and nests that shard's own planner output; executionStats also contains statistics for each accessed shard. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)

## How it works

- SHARD_MERGE does not by itself mean every shard in the cluster participated. MongoDB can target a subset of shards, and an example with multiple but not all shards still uses SHARD_MERGE; inspect winningPlan.shards to identify participants and compare that list with cluster membership when checking for a broadcast. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/core/sharded-cluster-query-router/)

## Comparisons and alternatives

- Aggregation explain generally returns a top-level stages array rather than find's query-plan tree. MongoDB documents an exception: if the entire pipeline is optimized away, a query-plan tree can fulfill it and no aggregation stage information appears. For sharded aggregation, mergeType, splitPipeline, and shards show the merge location, pipeline split, and work performed by each shard. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)
- MongoDB says explain fields are subject to change, and plan-tree layout differs between the classic and slot-based execution engines. Check the returned explainVersion and server version against matching documentation instead of assuming a fixed tree. (high confidence) (verified as of 2026-10-20) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)

## Facts and statements

- For a sharded find explain, queryPlanner.winningPlan is the mongos-level plan and its shards array lists accessed shards; each entry carries that shard's query-planner information and local winningPlan. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)
- A MongoDB v8.0 setQuerySettings explain example shows a SINGLE_SHARD winning plan with one entry in winningPlan.shards. MongoDB v8.3 describes SHARD_MERGE as merging results from shards and says mongos can target a subset of shards. SHARD_MERGE therefore does not by itself establish an all-shard broadcast; inspect the shards array to see which shards participated. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.0/reference/command/setquerysettings/)
- In sharded find executionStats, per-shard statistics are under executionStats.executionStages.shards[]. The root statistics summarize router output, while each array entry names a shard and carries its own execution statistics. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)
- Do not infer one-shard targeting only from a shard-key predicate. MongoDB documents that some queries containing the shard key still broadcast depending on data distribution and selectivity; read the explain stage and returned shards array to observe the actual execution path. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/core/sharded-cluster-query-router/)
- In mongos queryPlanner output, SINGLE_SHARD identifies a plan that uses one shard, while SHARD_MERGE identifies the router stage that merges results from multiple shards. Read each shard entry's nested winningPlan to see that shard's local plan; the root stage describes router coordination. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)
- With executionStats verbosity, compare executionStats.executionStages.shards entries to inspect per-shard work. The top-level totalKeysExamined and totalDocsExamined aggregate work across accessed shards, so aggregate totals alone can hide differences between shard entries. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.3/reference/explain-results/)
