Plan cache flushes on index DDL
Parent: Hidden indexes and safe index removal · Published reference · snapshot 2026-10-31
Also known as: Plan cache invalidation on index DDL (hide, drop, create)
↓ Facts as markdownall context files
Source-anchored research for Plan cache flushes on index DDL. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- Methodological inference: when comparing compound-index and index-union alternatives, an index creation, drop, or hide is also a cache-state intervention. Inspect collection cache entries with $planCacheStats or getPlanCache().list() and distinguish executions immediately after DDL from later executions before attributing a timing difference solely to index structure. (medium confidence) [source]
How it works
- Creating or dropping an index invalidates cached query plans. MongoDB documents the clearing scope as the relevant collection; Percona lists index creation and dropping as invalidation triggers, and Alibaba Cloud independently documents clearing on index drop. (high confidence) [source]
- An index addition or deletion can invalidate cached plans on the same collection even when that index is unrelated to the target query; invalidation is broader than removing only plans that used the changed index. (medium confidence) [source]
- MongoDB's documented plan-cache flush triggers include hiding an index, in addition to creating and deleting indexes; a reversible hide operation therefore still changes the collection's cache state. (low confidence) [source]
- Hiding an already hidden index is documented as a no-op on the index, although hideIndex still writes an empty oplog entry. The hidden-index manual distinguishes such calls from actual visibility changes when describing $indexStats resets; these statements alone do not establish whether the no-op flushes the plan cache. (medium confidence) [source]
Problems, failure modes and limitations
- For an index comparison, record DDL and inspect actual cache state with $planCacheStats or PlanCache.list(); explain bypasses existing cache entries and does not populate them, so it cannot demonstrate cache warm-up. (medium confidence) [source]
- SERVER-60067 proposed evicting only SBE cached plans dependent on a dropped index. Its recorded resolution is Won't Do and it lists no fix version, so the proposal cannot substantiate a claim that dependency-only index-drop invalidation shipped. (low confidence) (verified as of 2022-12-06) [source]
Comparisons and alternatives
- PlanCache.clear() explicitly removes a collection’s cached plans; PlanCache.clearPlansByQuery() permits targeted removal instead of changing indexes merely to force cache invalidation. (medium confidence) [source]
- The historical SBE design in SERVER-60066 uses a process-global plan cache, unlike the classic engine's per-collection cache. It requires collection-dependent invalidation on collection drop; collection-scoped invalidation should not be described as necessarily having a physically separate cache in every execution engine. (low confidence) [source]
Facts and statements
- Hiding an index clears the collection plan cache. It also removes that index from planner consideration while retaining the maintained index, enabling a reversible experiment before dropping it. (medium confidence) [source]
- SERVER-32943 documents a historical background-build race: building an index flushed the cache, a concurrent query cached a plan without the unfinished index, and completion did not flush again. The issue records fixes in 3.6.9 and 4.0.0-rc0; its description is evidence of a legacy defect, not proof that current builds leave such plans cached. (low confidence) (verified as of 2023-10-29) [source]
- The July 2026 description of SERVER-131831 identifies CollectionQueryInfo::rebuildIndexData and CollectionQueryInfo::clearQueryCache among the query-owned functions called by index DDL paths to maintain classic plan-cache consistency. It proposes consolidating those calls while preserving behavior; it does not establish a released version containing the refactor. (low confidence) (verified as of 2026-07-23) [source]
- If an index filter restricts a query to an index that is subsequently hidden or absent, the optimizer can fall back to a collection scan; clearing cached plans does not make the filtered index available again. (medium confidence) [source]
- A hidden index is excluded from query-plan selection but remains maintained. Hiding lets an operator evaluate removal and then restore planner access by unhiding, without rebuilding the index. (medium confidence) [source]
Children
- No children recorded.