Compound shard-key prefix targeting
Parent: Shard key selection for query isolation · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Compound shard-key prefix targeting. 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.
How it works
- Treat a multi-shard explain plan as evidence of fan-out, not automatic evidence of a missing prefix: targeted operations may legitimately contact several shards. Inspect actual shard participation when checking isolation. (medium confidence) [source]
Comparisons and alternatives
- Design inference: for tenant-scoped reads, putting tenantId first in {tenantId: 1, entityId: 1} makes the tenant predicate available for prefix targeting; adding entityId alone does not supply that leading prefix. Choose field order from common query predicates rather than only from document cardinality. (medium confidence) [source]
- Design inference: verify the actual contacted shards for representative prefix queries and deployed data placement instead of assuming an efficient local index or a selective-looking filter proves single-shard routing. Mongos merges results from its targeted shards, so broader fan-out adds distributed work. (medium confidence) [source]
Facts and statements
- For shard key {a:1,b:1,c:1}, {a} and {a,b} are leading prefixes that mongos can use to target a shard or set of shards; the full key also supports targeting. (high confidence) [source]
- A prefix predicate does not guarantee a single-shard read. Depending on data distribution and predicate selectivity, matching ranges may reside on multiple shards, and even a query containing shard-key fields may require a broadcast. (high confidence) [source]
- Router targeting and local index selection are separate: mongos identifies candidate shards from shard-key metadata, while each contacted shard can use the most efficient eligible local index, including an index other than the shard-key index. (low confidence) [source]
- Yorkie documents a concrete prefix-omission case: its Clients housekeeping query filters on _id and status but omits project_id, and the design explicitly labels it a scatter-gather query accepted for infrequent maintenance. The documented Clients key begins with project_id. (low confidence) [source]
- Percona demonstrates compound-key zone placement using a leading location field. This illustrates that constraining eligible placement requires configured zone ranges and assigned shards, beyond simply choosing a prefix that queries can target. (medium confidence) [source]
- For {customerId:1,createdAt:1}, a customerId equality filter supports prefix targeting; a createdAt-only filter omits the prefix and generally requires scatter-gather. (high confidence) [source]
- Design implication: leading tenant equality can preserve routing locality while suffix fields permit one tenant to span multiple chunks and shards. Yorkie explicitly describes splitting within a project using a compound key; prefix targeting therefore must not be treated as guaranteed tenant co-location. (medium confidence) [source]
- Choose fields around real query filters and aim to minimize shards contacted. Percona describes each shard as a coarse index and warns that an apparently transparent mongos query can hide expensive cross-shard execution. (medium confidence) [source]
Children
- No children recorded.