# Hashed shard keys and index support > Source-anchored research for Hashed shard keys and index support. Run status: COMPLETED. Parent: [Covered queries on sharded collections](https://llms-explorer.com/tree/covered-queries-on-sharded-collections/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/hashed-shard-keys-and-index-support/ ## Structure and components - A compound hashed index contains one hashed field together with ordinary ordered fields. The hashed field may occur before or after non-hashed fields; Percona demonstrates both {_id:"hashed",location:1} and {location:1,_id:"hashed"}. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - For a query through mongos to be covered on a sharded collection, the same index must contain the shard key, the query fields including internally needed fields, and returned fields. Including the shard key is necessary but does not override hashed-index limitations. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/query-optimization.md) - MongoDB documents single-field and compound hashed sharding. A compound hashed index hashes exactly one component and combines it with ordinary indexed components; a non-hashed prefix can define zone ranges. Percona dates compound hashed index support to MongoDB 4.4. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - MongoDB issue records describe covered plans using compound indexes with hashed and ordinary components. SERVER-99889 reports incorrect SBE results when indexed paths share a prefix, and SERVER-115573 describes restricting SBE eligibility. These records scope the blanket manual statement; they do not prove that an original hashed field value can be projected from its hash. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-99889) ## Problems, failure modes and limitations - The hashed-index manual explicitly states that hashed indexes cannot cover a query. Treat this as documented guidance, with the compound-index implementation caveat recorded under disagreements; do not infer that every query against a collection with hashed sharding must fetch documents. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md) - A hashed index cannot itself enforce a unique constraint. An additional ordinary unique index on the same field can enforce original-value uniqueness while the collection retains hashed shard distribution; the MongoDB community example explicitly describes this combination. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md) - Hashed indexes cannot become multikey: an indexed array is prohibited, and an array in any component of a compound hashed index is prohibited. Adding an array-valued projection field to such an index is therefore not a valid covering-index workaround. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md) ## Comparisons and alternatives - Historical bug SERVER-48471 describes a hashed-index build concurrent with writes being incorrectly marked multikey, causing shardCollection to fail with "couldn't find valid index for shard key" despite an index existing. The issue records fixes in 4.2.12, 4.4.4 and 4.9.0; diagnose it as a historical index-eligibility bug rather than a coverage feature. (low confidence) (verified as of 2026-10-31) — [source](https://jira.mongodb.org/browse/SERVER-48471) ## Facts and statements - Hashed indexes store hashes of indexed field values and support hash-based sharding; createIndex({field: "hashed"}) declares this index type. Indexing a hash is distinct from retaining the original field value for a covering projection. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md) - Adding ordinary fields to a compound hashed index does not itself prove coverage. The manual gives no compound-index exception to its hashed-index coverage prohibition; treat coverage through this index as unsupported unless a version-specific execution plan establishes a narrower exception. This is a documentation-based inference, not a tested compound case. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-hashed.md) - For a single-field hashed shard key, equality matches can target one shard, while hashing removes original-value range locality and range queries are more likely to broadcast. Targeting one shard does not itself establish index coverage. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/hashed-sharding.md) - MongoDB permits dropping a hashed shard-key index starting in 7.0.3, 6.0.12 and 5.0.22. The dedicated procedure recommends retaining a supporting ordinary index for shard-key queries and warns that dropping the hashed index disables collection balancing and orphan cleanup until appropriate recovery; this is not a general index-removal recommendation. (medium confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/manual/tutorial/drop-a-hashed-shard-key-index.md) - Hashed shard-key index retention is version-dependent: MongoDB documents the ability to drop that index starting in 7.0.3, 6.0.12, and 5.0.22. Advice that a supporting shard-key index can never be dropped needs this exception. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/sharding-shard-key-indexes.md) - The current drop-index procedure recommends a supporting non-hashed index to avoid collection scans for shard-key predicates. Dropping the hashed shard-key index disables balancing for that collection until the index is recreated, so dropping it is not a coverage optimization without operational consequences. (low confidence) (verified as of 2026-10-31) — [source](https://www.mongodb.com/docs/manual/tutorial/drop-a-hashed-shard-key-index.md)