explain() executionStats reading
Parent: MongoDB Compound Index Design: ESR, Selectivity, Covering and Multikey Bounds · Published reference · snapshot 2026-10-21 · skill ranked-29798f23
↓ Facts as markdownall context files
Source-anchored research for explain() executionStats reading. 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-to and procedures
- Use nReturned, totalKeysExamined, and totalDocsExamined together: nReturned counts documents returned by the winning plan, totalKeysExamined counts scanned index entries, and totalDocsExamined counts document examinations, including filtered-out and repeated examinations. A gap is a clue to inspect the stage tree and filters, not a universal efficiency verdict, because stage counts can describe intermediate work and a document can be counted more than once. (high confidence) (verified as of 2026-10-21) [source]
Comparisons and alternatives
- MongoDB defines executionTimeMillis as the time spent on plan selection plus query execution, including the plan trial phase but excluding network transmission. MongoDB warns that explain timing may differ from steady-state query latency because explain bypasses the plan cache and does not cache its selected plan. Use it with work counters, and measure representative normal traffic when latency is the target. (high confidence) (verified as of 2026-10-21) [source]
Facts and statements
- For mongosh cursor.explain(), queryPlanner is the default. The executionStats verbosity chooses the winning plan, runs it to completion, and reports its execution statistics; it does not report completed run statistics for rejected plans. allPlansExecution adds partial candidate-plan statistics captured during plan selection. (high confidence) (verified as of 2026-10-21) [source]
- Read `executionStats` by comparing top-level `nReturned`, `totalKeysExamined`, and `totalDocsExamined`, then inspect `executionStages` from its leaf stages toward the root. Stage names and child fields show where the plan scans (`COLLSCAN` or `IXSCAN`), fetches documents (`FETCH`), and performs other work. The plan tree can be nested differently across classic and slot-based execution engines and can change between MongoDB versions. (high confidence) (verified as of 2026-10-21) [source]
- Do not add `executionTimeMillisEstimate` values across stages to reconstruct total query duration. MongoDB documents these stage timings as estimates, and its explain implementation adds the overall elapsed-time value at the top level without changing individual stage timings. (high confidence) (verified as of 2026-10-21) [source]
- A Percona example published 2023-07-26 shows a regex query returning 19,851 documents before and after adding a name index: totalDocsExamined fell from 10,000,000 to 19,851, while totalKeysExamined rose from 0 to 10,000,000 and executionTimeMillis changed from 4,171 to 4,283. This historical case shows why an IXSCAN or a lower document-examination count alone does not prove lower elapsed time. (high confidence) (verified as of 2023-07-26) [source]
- MongoDB documents that explain output can vary between the classic and slot-based execution engines and that documented fields may change. Amazon DocumentDB separately defines docsExamined as stage-local and totalDocsExamined as a total across its execution stages. Treat those DocumentDB details as product-specific and verify field scope against the server and version being measured. (high confidence) (verified as of 2026-10-21) [source]
Children
- No children recorded.