# Multikey indexes and sort provision (multikeyPaths) > Source-anchored research for Multikey indexes and sort provision (multikeyPaths). Run status: COMPLETED. Parent: [SORT_MERGE and $in sort expansion](https://llms-explorer.com/tree/sort-merge-and-in-sort-expansion/) · 4 facets · 14 facts · page: https://llms-explorer.com/tree/multikey-indexes-and-sort-provision-multikeypaths/ ## Structure and components - multiKeyPaths identifies the indexed path components that traverse arrays. A compound index may have isMultiKey: true while an individual indexed field has an empty multiKeyPaths list; therefore the overall flag does not show which sort fields are multikey. (high confidence) — [source](https://dev.to/franckpachot/mongodb-multikey-indexes-and-index-bound-optimization-ol9) - An index on an array field is multikey and stores entries for array values, so one document can contribute multiple index entries. MongoDB creates this index type automatically when indexed values contain arrays. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md) ## How it works - SERVER-19402 defines single-array ascending document sorts using the lowest-valued array element and descending sorts using the highest-valued element. SERVER-32525 demonstrates the historical correctness problem: bounding a.b can omit the a.c element needed for the document sort key when both descend through array a. (medium confidence) — [source](https://jira.mongodb.org/browse/SERVER-19402) - SERVER-53675 documents that multikey metadata can conservatively retain paths after collection data stops containing those arrays. It also identifies pre-3.4 indexes without path-specific metadata as a cause of unnecessary blocking sorts. Current document values alone therefore do not establish the metadata available to sort planning. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-53675) - A bound on one field of an array of objects can prevent its sibling field from providing sort order, even when the sibling has full bounds. SERVER-31898 demonstrates that filtering a.b changes which a.c keys are scanned because both paths traverse array a. The planner tests likewise require a separate sort in shared-prefix cases. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-31898) - The retrieved MongoDB master planner tests allow $in expansion into merge-sorted scans for index {a:1,"b.c":1} when a is multikey and b.c is scalar. The same query with b.c traversing an array instead retains a separate sort. This is evidence about the inspected source tests, not a guarantee for every released server version. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/query_planner_array_test.cpp) - The retrieved planner tests also permit merge-sorted $in scans with index {a:1,b:1,c:1} when only indexed field c, which is unused by the sort, is multikey and the query sorts on scalar b. An index being multikey somewhere is therefore insufficient grounds to rule out sort expansion. (low confidence) (verified as of 2026-10-30) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/query_planner_array_test.cpp) - When diagnosing multikey sorting, inspect the actual plan, per-field multiKeyPaths, and indexBounds together. A successful indexed filter is insufficient evidence of index-provided ordering; this follows from the documented multikey sort restrictions and the planner tests that place a separate sort above an index scan. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md) ## Comparisons and alternatives - The May 2024 PHONE example reports SORT above FETCH and IXSCAN despite full bounds on PHONE.PHONE_ID: PHONE.PHONE_NUMBER is range-bounded and both fields list PHONE in multiKeyPaths. This is a concrete shared-array-prefix example, rather than evidence that every multikey index sort blocks. (medium confidence) — [source](https://www.mongodb.com/community/forums/t/compound-multikey-index-not-used-in-sort-and-range-query/279425) ## Facts and statements - A multikey index creates index entries from array elements; one document can therefore contribute multiple keys. Repeated equal elements within one document do not require duplicate identical index entries. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md) - For a sort on an array field indexed by a multikey index, the manual requires full [MinKey, MaxKey] bounds on all sort fields and no bounded multikey-indexed field sharing a path prefix with the sort pattern to avoid the additional in-memory sort. These are additional eligibility restrictions, not a guarantee that the planner selects that index. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/indexes/index-types/index-multikey.md) - The inspected MongoDB planner test CanExplodeMultikeyIndexScanForSortWhenSortFieldsAreNotMultikey uses index {a:1,"b.c":1}, multikey metadata only on a, filter {a:{$in:[1,2]}}, and sort {"b.c":1}. It expects a mergeSort over two point-bound index scans, showing that a multikey filter field does not categorically prohibit sort expansion. This is a source-test observation, not a release-wide execution guarantee. (low confidence) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/query_planner_array_test.cpp) - The adjacent test CantExplodeMultikeyIxscanForSortWithPathLevelMultikeyMetadata marks b.c multikey through b. For the same $in filter and sort it expects a blocking sort over one index scan, even though b.c has full bounds. Do not infer that full sort-field bounds alone make $in expansion legal. (low confidence) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/query_planner_array_test.cpp) - Bounding an array sort field can discard the element that determines document order. SERVER-31898 illustrates find({myArray: {$gte: 5}}).sort({myArray: 1}): arrays [1,6,7] and [3,4,5] must order by 1 and 3, whereas scanning only keys at least 5 would encounter 5 before 6. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-31898)