Index intersection is a query optimization technique where MongoDB combines multiple indexes to satisfy a query, but it is rarely used in practice and should not be relied upon; a single well-designed compound index is almost always the better choice.
Index intersection is a feature that allows MongoDB to use more than one index to fulfill a single query by intersecting the results from multiple index scans . While this capability exists, the official MongoDB documentation and community experts consistently warn against relying on it. In practice, the query optimizer rarely selects index intersection plans because they are less efficient than using a properly designed compound index . The general principle is that schema designs should not rely on index intersection; instead, compound indexes should be used .
When MongoDB uses index intersection, it scans multiple indexes separately and then intersects the results to find documents that match all query conditions. This can happen in two ways: AND_SORTED (which merges sorted index results) or AND_HASH (which builds a hash table of results from one index and probes it with results from another) . For example, with indexes on { qty: 1 } and { item: 1 }, MongoDB could intersect them to satisfy a query like find({ item: "abc123", qty: { $gt: 15 } }) . However, this intersection process introduces significant overhead—it requires scanning potentially large portions of multiple indexes and performing computationally expensive set operations in memory .
A single compound index is almost always superior to index intersection for several reasons. First, compound indexes provide more selective scans—they can narrow down results using multiple fields in a single index traversal, whereas index intersection requires scanning potentially large portions of multiple indexes and then intersecting them in memory . Second, compound indexes require only one index lookup operation, while index intersection requires multiple index scans plus the intersection computation . Third, compound indexes can support sorting directly, while index intersection cannot be used when the query includes a sort that doesn't match one of the intersected indexes . A MongoDB Developer Advocate confirms that index intersection is "never used in practice because in real-world workloads it almost never gets chosen by the query planner" .
Rarely selected by optimizer: The query planner disfavors index intersection plans to prevent bad plan selection
Cannot support sorting: Index intersection does not apply when the sort operation requires an index separate from the query predicate
Higher overhead: Intersecting results requires additional computation and memory compared to a single index scan
Hash-based intersection disabled: Hash-based index intersection is disabled by default, and sort-based intersection is disfavored
Despite the superiority of compound indexes, there are scenarios where maintaining separate single-field indexes is still valuable. If you have multiple query patterns that use different combinations of fields, a set of single-field indexes might cover all patterns, whereas you would need multiple compound indexes to achieve the same coverage . For example, if you have queries that filter on a alone, b alone, and sometimes both a and b, having single-field indexes on a and b could support all three patterns. However, the query for both fields would ideally use index intersection, which is suboptimal. A better approach might be to have single-field indexes for the frequent single-field queries and a compound index for the combined query, accepting the write overhead of an additional index.
The MongoDB documentation is unequivocal: "Schema designs should not rely on index intersection. Instead, compound indexes should be used" . This recommendation is echoed throughout the community—a MongoDB forum post confirms that "compound index is way more efficient than individual indexes and MongoDB isn't very efficient at doing index intersections because compound indexes are always better" . Another community expert advises that for queries combining multiple fields, "the best index would be a compound index" .
To determine whether your query is using index intersection or a compound index, always use explain("executionStats"). If you see AND_SORTED or AND_HASH stages in the execution plan, MongoDB is attempting index intersection . This should be treated as a red flag indicating that a compound index would likely improve performance. The presence of a FETCH stage with high totalDocsExamined relative to nReturned can also indicate inefficient index usage . For query patterns that need to support multiple field combinations, carefully analyze your workload and consider a strategy that prioritizes the most critical queries with compound indexes while accepting that some query patterns may require separate indexes.
For the vast majority of use cases, a well-designed compound index is superior to relying on index intersection with multiple single-field indexes. Compound indexes provide better performance, support sorting, and are consistently chosen by the query optimizer. While index intersection exists as a fallback mechanism, it should never be part of your primary indexing strategy. When designing indexes, start with compound indexes that match your most important query patterns, following the ESR (Equality, Sort, Range) rule for field order. Only consider single-field indexes when you have multiple query patterns that cannot be efficiently covered by a limited set of compound indexes, and be prepared to accept the performance trade-offs for queries that require combining them.