# Plan cache flushes on index DDL > Source-anchored research for Plan cache flushes on index DDL. Run status: COMPLETED. Parent: [Hidden indexes and safe index removal](https://llms-explorer.com/tree/hidden-indexes-and-safe-index-removal/) · 5 facets · 14 facts · page: https://llms-explorer.com/tree/plan-cache-flushes-on-index-ddl/ ## 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](https://www.mongodb.com/docs/manual/core/query-plans.md) ## 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](https://www.mongodb.com/docs/manual/core/query-plans.md) - 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](https://proxy-hk.tencentcloud.com/document/product/240/81407) - 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](https://www.mongodb.com/docs/manual/core/query-plans.md) - 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](https://www.mongodb.com/docs/manual/core/index-hidden.md) ## 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](https://www.mongodb.com/docs/manual/core/query-plans.md) - 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](https://jira.mongodb.org/browse/SERVER-60067) ## 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](https://www.mongodb.com/docs/manual/core/query-plans.md) - 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](https://jira.mongodb.org/browse/SERVER-60066) ## 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](https://www.mongodb.com/docs/manual/core/query-plans.md) - 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](https://jira.mongodb.org/browse/SERVER-32943) - 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](https://jira.mongodb.org/browse/SERVER-131831) - 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](https://www.mongodb.com/docs/manual/reference/command/planCacheSetFilter.md) - 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](https://www.mongodb.com/docs/manual/core/index-hidden.md)