When would you attach hint() to a MongoDB query instead of letting the planner choose?

## What hint() actually does By default MongoDB's planner enumerates candidate plans for a query shape, runs them side by side for a short trial, scores them by measured productivity, keeps the winner and caches it. `hint()` short-circuits that: it tells the server to consider only the named index (or, with `$natural`, no index at all). The query still returns correct results — a hint changes the access path, never the semantics. Accepted forms: by key pattern, `db.orders.find(q).hint({ status: 1, createdAt: -1 })`; by index name, `db.orders.find(q).hint("status_1_createdAt_-1")`; and `db.orders.find(q).hint({ $natural: 1 })` to force a collection scan. If you name an index that does not exist, the command **errors** — it does not silently fall back. That failure mode is one of the strongest arguments against sprinkling hints through application code: dropping an index becomes a breaking change instead of a performance change. Hints are not limited to `find`: `update`, `delete` and `findAndModify` accept a hint too, which matters when a bulk update picks a poor path. ## The legitimate use: measurement The honest answer to this interview question is that `hint()` is mostly a *tool for the person tuning the query*, not a production setting. The workflow: 1. Run `explain("executionStats")` normally. Record `nReturned`, `totalKeysExamined`, `totalDocsExamined`, `executionTimeMillis`, and which index won. 2. Re-run with `.hint(candidateIndex)` for each plausible index. Same counters. 3. Compare. If a candidate examines dramatically fewer keys, you have evidence for reordering or building an index — and evidence for *why*, not just a feeling. 4. `hint({ $natural: 1 })` gives you the baseline: what a plain collection scan costs. Sometimes the scan is close enough that the index is not worth its write cost. This is also how you validate a new index before dropping the old one, and how you demonstrate to a reviewer that a proposed index actually helps. ## When pinning is defensible A hint in shipped code is justified only with a stated reason and a review date. Real cases: - **Plan instability.** Two plans score similarly during the trial, so the winner flips depending on which documents the trial happened to touch, and one of them has a far worse tail latency. Pinning the safe one bounds the worst case. - **A query whose selectivity varies wildly by parameter**, where the plan chosen for one set of values is wrong for another. - **A maintenance or migration job** where you want a predictable scan or a predictable index walk, and predictability of runtime matters more than optimality. In every case the better first move is to fix the cause: build the index the query actually needs (equality fields first, then sort, then range), remove a redundant index that confuses the choice, or reshape the query. A hint treats the symptom. ## What pinning costs you - **It freezes a decision made against today's data.** Distributions shift; the index that was right at one million documents may be wrong at a hundred million. - **It blocks future improvement.** A better index added later will never be used by the hinted query, and nobody will notice. - **It couples code to index names.** Renaming or dropping an index breaks the query outright. - **It hides regressions.** The plan no longer changes, so the usual symptom that tells you the data changed — a plan flip — never fires. ## Related knobs, and what they are not Do not conflate `hint()` with clearing the plan cache. A cached plan can go stale, and the server re-evaluates a cached plan when it starts performing much worse than when it was cached; you can also clear cache entries administratively. That is a different lever from forcing an index and is usually the right one when the complaint is "it was fast until yesterday". Also note that a hint interacts with coverage and sorting: hinting an index that cannot supply the query's sort order will produce a blocking `SORT` stage that the planner might have avoided by choosing differently — another reason to always look at the hinted plan's explain output rather than assuming the hint helped. ## Answering well Lead with the diagnostic use, name `$natural` as the force-a-scan form, mention the hard error on a missing index, and close with the tradeoff — a hint is a decision you have to keep re-justifying, while a correct index keeps working on its own.