<!-- llms-explorer concept facts · https://llms-explorer.com/tree/compound-shard-key-prefix-targeting/ · pack 2026-10-30 · ~1078 tokens -->

# Compound shard-key prefix targeting

> Source-anchored research for Compound shard-key prefix targeting. Run status: COMPLETED.

Parent: [Shard key selection for query isolation](https://llms-explorer.com/tree/shard-key-selection-for-query-isolation/) · 3 facets · 11 facts · page: https://llms-explorer.com/tree/compound-shard-key-prefix-targeting/

## 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)

## 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)

## 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://github.com/yorkie-team/yorkie/blob/main/docs/design/mongodb-sharding.md)
- 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](https://www.percona.com/blog/sharding-with-zones-based-on-compound-shard-keys-on-mongodb-4-4/)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
- 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](https://www.mongodb.com/docs/manual/core/sharded-cluster-query-router.md)
