COUNT_SCAN and sharded count accuracy
Parent: Covered queries on sharded collections · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for COUNT_SCAN and sharded count accuracy. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- COUNT_SCAN is not necessarily constant-time: the SERVER-39191 direct-shard log examined roughly 6.9 million index keys despite examining zero documents. A covered count can therefore still do substantial index work. (low confidence) [source]
Structure and components
- SERVER-103369 proposes orphan-chunk skipping inside COUNT_SCAN when the index contains the shard key, and describes additional FETCH support as necessary for the more general case. The issue page is unresolved with no fix version and was last updated April 10, 2025; it is a proposal, not proof of released support. (low confidence) (verified as of 2026-10-31) [source]
How it works
- MongoDB documents index-only count eligibility when predicates use indexed fields and a single contiguous index-key range. A first-hand Stack Overflow question reports COUNT_SCAN for equality and IXSCAN for an $in predicate. This is evidence about query shape, not a guarantee that sharding ownership filtering can be omitted. (medium confidence) [source]
Comparisons and alternatives
- Inference from the documented planner history and the separate metadata-count defect: a faster direct-shard plan or the presence of an index does not by itself establish a correct cluster-wide count. Validate the operation routed through mongos and its shard ownership handling rather than summing physical shard counts as an accuracy workaround. (medium confidence) [source]
Facts and statements
- A count command without a query predicate reads collection metadata. On sharded collections, orphaned documents or an ongoing chunk migration can make that count inaccurate; this metadata shortcut must be distinguished from an index-driven COUNT_SCAN plan. (high confidence) [source]
- For counts that must exclude orphaned documents, MongoDB documents countDocuments() as an aggregation-based alternative to metadata counts and recommends aggregation with $count for sharded collections. These recommendations address orphan and metadata errors; they do not promise that separately issued reads observe an identical moment during concurrent writes. (high confidence) [source]
- SERVER-39191 records a MongoDB 4.0.5 workload where a direct-shard count used COUNT_SCAN with zero documents examined, while the mongos-routed count used IXSCAN and examined documents to filter orphans. The issue lists fix version 4.9.0; its old description must not be generalized into a permanent ban on COUNT_SCAN for sharded counts. (medium confidence) (verified as of 2026-10-31) [source]
- Alibaba Cloud documents checking each shard in find().explain("executionStats"): nonzero chunkSkips in SHARDING_FILTER indicates orphaned documents. Its example passes 102 documents from FETCH, filters two orphans, and returns 100. This can help diagnose a count discrepancy without treating every index entry as a logically owned document. (low confidence) (verified as of 2026-10-31) [source]
- Tencent's consistency-verification guide says its row-count check obtains metadata counts with estimatedDocumentCount() or stats(), which can disagree with actual rows after unexpected shutdown or with orphans. It recommends countDocuments() for comparison and warns about scanning cost. (low confidence) (verified as of 2026-10-31) [source]
- MongoDB's historical fix made counts with predicates sharding aware starting in the 4.0 release series. Predicate-free metadata counts remained separate follow-on work; old statements that all sharded count() operations overcount orphans need this scope. (high confidence) [source]
- For an empty-filter countDocuments(), MongoDB documents a full collection scan by default and suggests hinting the _id_ index or using an all-matching indexed predicate. This optimization does not promise COUNT_SCAN or zero document fetches for every sharded plan. (medium confidence) [source]
Children
- No children recorded.