# SBE plan cache keys and parameterized explode-for-sort plans > Source-anchored research for SBE plan cache keys and parameterized explode-for-sort plans. Run status: COMPLETED. Parent: [SORT_MERGE and $in sort expansion](https://llms-explorer.com/tree/sort-merge-and-in-sort-expansion/) · 5 facets · 16 facts · page: https://llms-explorer.com/tree/sbe-plan-cache-keys-and-parameterized-explode-for-sort-plans/ ## Structure and components - In the r7.0.12 SBE encoder, a parameterized InMatchExpression with a sort contributes min(maxScansToExplode + 1, number of unique equalities) to the key. Counts at or below the cap remain distinct; larger counts share this component. This does not guarantee that the entire keys match or that the planner actually chooses explosion. (high confidence) — [source](https://github.com/mongodb/mongo/blob/r7.0.12/src/mongo/db/query/canonical_query_encoder.cpp) - The r7.0.12 encoder omits the $in equality-count component when there is no sort. SERVER-83712 records this reduction of unnecessary key fragmentation, with fix versions including 7.0.12 and 7.3.3. Treat earlier 7.0 patch releases separately. (high confidence) — [source](https://github.com/mongodb/mongo/blob/r7.0.12/src/mongo/db/query/canonical_query_encoder.cpp) ## How it works - Explode-for-sort can replace one index scan with several scans combined in sorted order to avoid a blocking sort. For a parameterized $in predicate, its unique equality count matters because it can determine the number of merge branches in the cached execution tree. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-66459) - SERVER-89436 gives find({a:"foo",b:[1]}) and find({a:"bar",b:[2]}) as queries sharing a classic key but having different historical SBE keys because array equality literals are not parameterized. Equality to an array is distinct from parameterized $in cardinality. (medium confidence) (verified as of 2025-04-11) — [source](https://jira.mongodb.org/browse/SERVER-89436) - When investigating similar $in queries, compare their actual planCacheKey values and cached entries with profiler evidence such as fromPlanCache, replanned, and replanReason. A different key alone does not prove that MongoDB retrieved and rejected an inefficient cached plan; the latter diagnosis requires execution evidence. This is a diagnostic inference from the documented fields and Percona's cache-reuse examples. (medium confidence) — [source](https://www.mongodb.com/docs/manual/core/query-plans/) - MongoDB documents planCacheKey as depending on both the plan-cache query shape and supporting indexes. Different constants can change partial-index eligibility and produce different keys even when the documented query shape is the same, so $in cardinality is not the only possible cause of a key difference. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/query-plans/) ## Problems, failure modes and limitations - At r7.0.12, no-sort queries omit the extra parameterized $in count, and counts above the explosion limit share the maxScansToExplode + 1 sentinel. These remove particular key differences; all other key components must still match for reuse. (high confidence) — [source](https://github.com/mongodb/mongo/blob/r7.0.12/src/mongo/db/query/canonical_query_encoder.cpp) - Use normal query executions and profiler/cache inspection to test reuse: MongoDB documents that explain ignores existing cache entries and does not create a new one. Explain output by itself therefore cannot demonstrate that repeated parameterized executions reused the SBE cache. (low confidence) — [source](https://www.mongodb.com/docs/manual/core/query-plans/) ## Comparisons and alternatives - SERVER-66459 documents an old correctness failure: explosion discarded interval evaluation trees, causing scans to retain literal high/low keys instead of recomputing bounds for new parameters. A subsequent query using the cached plan could miss matching documents. This is a historical bug description, not evidence that all current SBE executions are affected. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-66459) ## Facts and statements - SERVER-89436 describes the historical SBE cache as mapping a conservatively parameterized shape to a clonable executable SBE plan. The r7.0.12 encoder replaces eligible constants with parameter markers; structural compatibility constrains reuse. (high confidence) — [source](https://jira.mongodb.org/browse/SERVER-89436) - SERVER-88892 proposes creating the required number of cloned index-scan branches beneath a cached SortedMergeStage after runtime parameter binding. The reviewed issue is Open with no fix version; it does not establish shipped runtime branch resizing. (low confidence) (verified as of 2024-05-01) — [source](https://jira.mongodb.org/browse/SERVER-88892) - SERVER-83712 lists the no-sort key improvement as fixed in 7.0.12, 7.3.3, 8.0.0-rc1 and 8.1.0-rc0. Do not assume every older version omitted $in length without a sort. (low confidence) (verified as of 2026-09-21) — [source](https://jira.mongodb.org/browse/SERVER-83712) - SERVER-90415 records switching 8.0 release builds to the classic cache while retaining the SBE cache under the SBE-full feature flag. [redacted] separately describes 8.0 still parameterizing queries and generating interval evaluation trees while the SBE cache was unreachable. SBE execution does not itself establish SBE cache usage. (high confidence) (verified as of 2026-09-21) — [source](https://jira.mongodb.org/browse/SERVER-90415) - On the SBE-cache path described in SERVER-89436, MongoDB caches a clonable SBE execution plan using more conservative parameterization than the classic cache, which caches index-selection information and rebuilds the execution tree. This trades broader reuse for avoiding stage construction on an SBE cache hit. (low confidence) (verified as of 2025-04-11) — [source](https://jira.mongodb.org/browse/SERVER-89436) - SERVER-90415 records switching 8.0 and master release builds to the classic plan cache while retaining the SBE cache under the SBE-full feature flag. Its fix versions include 8.0.0-rc7 and 8.1.0-rc0. An operation executing in SBE therefore does not establish that the SBE execution-tree cache or its special $in cardinality encoding was used. (low confidence) (verified as of 2026-09-21) — [source](https://jira.mongodb.org/browse/SERVER-90415) - Netdata's MongoDB Top Queries function reads system.profile and exposes Plan Cache Key and Query Framework as separate hidden columns. This provides a concrete monitoring interface for comparing keys alongside classic/SBE execution, subject to profiling being enabled. (low confidence) (verified as of 2026-10-30) — [source](https://learn.netdata.cloud/docs/collecting-metrics/collectors/databases/mongodb)