<!-- llms-explorer concept facts · https://llms-explorer.com/tree/serverstatus-metrics-query-plancache-counters/ · pack 2026-10-31 · ~1580 tokens -->

# serverStatus metrics.query.planCache counters

> Source-anchored research for serverStatus metrics.query.planCache counters. Run status: COMPLETED.

Parent: [Replanning loops and replanReason](https://llms-explorer.com/tree/replanning-loops-and-replanreason/) · 5 facets · 17 facts · page: https://llms-explorer.com/tree/serverstatus-metrics-query-plancache-counters/

## How it works

- Monitor per-engine replanned deltas per unit time on each process; restart resets serverStatus statistics. This sampling method is an inference from counter semantics and restart behavior. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/serverstatus/)
- Read db.serverStatus().metrics.query.planCache for plan-cache statistics. MongoDB reports separate classic and sbe engine subdocuments; observe both when investigating replanning across engine workloads. (medium confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- classic.replanned and sbe.replanned count query plans discarded and re-optimized. The feature was designed to expose replanning frequency for diagnostics because high replanning rates may accompany performance problems. (medium confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)

## How-to and procedures

- Avoid copying the JusDB article's totalSizeOfPlanCacheEntriesInBytes example as the documented field name. The official planCache reference uses totalSizeEstimateBytes; JusDB also presents totalPlanCacheEntriesInvalidated, which is absent from the cited reference's planCache field list. (medium confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)

## Problems, failure modes and limitations

- Operational inference: compare counter changes over an observation interval and correlate increasing replanned values with query-specific slow-log replanReason evidence before attributing an instance-wide rise to a particular query loop. Tencent recommends this correlation, while MongoDB describes the counter as a frequency diagnostic. (medium confidence) — [source](https://proxy-hk.tencentcloud.com/document/product/240/81407)

## Comparisons and alternatives

- totalQueryShapes is an approximate cached-query-shape count, and totalSizeEstimateBytes measures plan-cache bytes. They describe cache occupancy rather than replanning events; the manual dates their grouping under planCache to 7.2 and names the older query.planCacheTotalQueryShapes and query.planCacheTotalSizeEstimateBytes paths. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)

## Facts and statements

- Inspect db.serverStatus().metrics.query.planCache; classic and sbe expose separate hits, misses and replanned counters. hits measures cached-plan reuse; misses measures absence followed by planning. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- The engine-specific replanned counters count discarded cached plans that undergo re-optimization. They are distinct from misses, which can occur without a previously cached plan. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- MongoDB documents classic.replanned and sbe.replanned as new in 8.0 and also available in 7.0.22; dashboards must check the deployed patch version before expecting these fields. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- classic.skipped and sbe.skipped distinguish cache-ineligible queries from ordinary cache misses. MongoDB documents these fields as new in 7.3; SERVER-75678 lists 7.3.0-rc0 and explicitly motivates separating ineligible queries from absent cache entries. (high confidence) (verified as of 2024-01-19) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- MongoDB 8.2 adds classic.replanned_plan_is_cached_plan and sbe.replanned_plan_is_cached_plan for replanning that produces an identical cached plan. Replanning therefore does not establish index switching. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/serverstatus/)
- The JusDB monitoring example names totalSizeOfPlanCacheEntriesInBytes; MongoDB documentation and the relocation ticket instead name totalSizeEstimateBytes. Verify actual server output before adopting that example. (medium confidence) — [source](https://www.jusdb.com/blog/mongodb-plancache-memory-issue-sbe-fix)
- SERVER-127703 records migration of PlanCache counters to OpenTelemetry metrics with fix version 9.0.0-rc0; the ticket alone does not establish availability in a deployed stable release. (low confidence) (verified as of 2026-10-23) — [source](https://jira.mongodb.org/browse/SERVER-127703)
- Within each engine subdocument, hits counts query plans found in cache and reused to avoid planning; misses counts plans absent from cache that went through planning. A miss is not the same event definition as discarded-plan re-optimization. (medium confidence) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- Do not assume every 8.0 patch exposes replanned. Although the manual labels the counters new in 8.0 and also available in 7.0.22, SERVER-87572 lists fix versions 8.1.0-rc0, 8.0.5, and 7.0.22. Check the deployed patch before treating an absent field as zero. (medium confidence) (verified as of 2025-06-12) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/)
- MongoDB 8.2 adds classic.replanned_plan_is_cached_plan and sbe.replanned_plan_is_cached_plan. They count replanning operations that produce a plan identical to one already in cache; SERVER-98987 describes this as wasteful replanning and lists 8.2.0-rc0. (medium confidence) (verified as of 2026-03-09) — [source](https://www.mongodb.com/docs/manual/reference/command/serverstatus/)
- A rising replanned counter does not prove an index switch: replanning can choose the same plan again. Treat the count as evidence of replanning work, and use the same-plan counters where available to distinguish that outcome. (medium confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/serverstatus/)
