Performance KB Articles
Parent: MongoDB KB Articles · Published reference · snapshot 2026-10-24 · skill mongodb-cohort-29539c2a7d1c
↓ Facts as markdownall context files
Source-anchored research for Performance KB Articles. 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.
How it works
- When a sort lacks a supporting index, a compound index matching the filter and sort can reduce sorting work; compound-index field order matters for query efficiency. (medium confidence) [source]
How-to and procedures
- Use explain execution statistics to compare document examination and index usage before and after a query or index change; a plan label alone is insufficient evidence of improvement. (high confidence) [source]
- Use $indexStats to investigate index usage, and hide suspected unnecessary indexes to evaluate query impact before dropping them. (medium confidence) [source]
Problems, failure modes and limitations
- Start performance troubleshooting by comparing latency with a baseline, finding slow operations in logs or profiler data, and correlating them with resource saturation and recent deployment changes. (high confidence) [source]
- An index scan is not universally faster than a collection scan. MongoDB documents this limitation, and experiments on MongoDB 7.0.1 found index-scan preference in cases where collection scans ran faster. (high confidence) [source]
- Validate a fix by rerunning representative queries and comparing latency, documents examined, index usage, slow-operation evidence, and resource metrics against the previous baseline. (high confidence) [source]
- Diagnose slow operations with profiler or slow-query evidence, then inspect explain plans for the specific query; a generic recommendation to add indexes is insufficient. (high confidence) [source]
Comparisons and alternatives
- Large index builds can interfere with normal operations. MongoDB recommends inspecting long-running operations and considering maintenance windows; SERVER-63095 supplies a historical user report of severe query slowdown during an index build, rather than proof that all builds cause such stalls. (medium confidence) [source]
- A collection scan is not automatically a performance defect: for some broad queries it can outperform an index scan, so judge measured work and latency rather than the presence of IXSCAN alone. (high confidence) [source]
- $indexStats usage counters are local to the node queried, count user-driven accesses rather than TTL maintenance, and reset on restart, index recreation, or index modification; zero accesses alone does not establish that an index is safe to drop. (medium confidence) [source]
- For a support escalation, collect the complete query shape and options, expected versus observed latency, representative executionStats, logs, recent changes, resource metrics, and deployment topology. (low confidence) [source]
Facts and statements
- Index design must balance read benefits with index maintenance on writes and storage costs; creating indexes for every field or query can degrade overall performance. (high confidence) [source]
- The 2024 First Past the Post study found an index-scan preference bias in experiments on MongoDB 7.0.1, including plans exceeding twice the runtime of the best tested alternative; this finding does not establish behavior in later releases. (low confidence) (verified as of 2024-09-25) [source]
- The database profiler writes detailed operation data into system.profile and can add performance and disk overhead; assess those costs before production use. (low confidence) [source]
- Tencent describes plan drift as a performance regression where the query pattern stays unchanged but the selected index changes. Its examples connect drift to unrepresentative parameter values, changing data distributions, and cache re-evaluation. (low confidence) [source]
- Treat cross-database benchmark rankings as workload-specific evidence: the stock-market study evaluated particular hybrid-cloud workloads, while a systematic review found that database performance studies often poorly reflect real use and omit replication detail. (medium confidence) [source]
- mongo-perf describes itself as an internal MongoDB microbenchmark tool without support for external users, and warns that its legacy-shell dependency has no guaranteed forward compatibility. A performance KB should check compatibility before proposing it as a general diagnostic tool. (low confidence) (verified as of 2026-10-23) [source]
- Compare latency with historical baselines or service objectives, correlate spikes with deployment changes and CPU, memory, or disk pressure, and verify fixes by rerunning representative queries. (low confidence) [source]
- An index scan can still be inefficient: compare examined keys and documents with returned results. Tencent documents indexed requests scanning roughly 1,500 entries to return only three documents. (high confidence) [source]
Children
- Execution-plan interpretation (frontier)
- Index write and cache overhead (frontier)
- Production profiler overhead (frontier)
- Query plan drift (frontier)
- Performance regression validation (frontier)
- Slow-query diagnosis with explain (frontier)
- Index selectivity and read/write tradeoffs (frontier)
- Safe index removal (frontier)
- Resource saturation and latency baselines (frontier)
Frontier under this node: Execution-plan interpretation, Index selectivity and read/write tradeoffs, Index write and cache overhead, Performance regression validation, Production profiler overhead, Query plan drift, Resource saturation and latency baselines, Safe index removal, Slow-query diagnosis with explain