The query planner usually picks a good index, but it can choose poorly when statistics are stale or a plan seemed cheaper on a small dataset. hint forces a specific index so you can compare plans, and explain shows whether the forced index actually helps.
Before you start
You should be comfortable with explain and indexes. This article uses the MongoDB shell.
Step-by-step walkthrough
Step 1: Read the plan before forcing anything
explain('executionStats') shows the chosen index, totalKeysExamined, totalDocsExamined and executionTimeMillis. A plan with many documents examined for few results is the clue. Understand the current choice before overriding it.
Step 2: Force the candidate index with hint
find(...).hint({ customerId: 1, status: 1 }) runs the query with that index. Compare its executionStats with the default. A hint is a diagnostic that confirms a hypothesis; if it does not improve the plan, the problem is elsewhere, such as a missing field in the index.
Step 3: Prefer fixing the plan over keeping the hint
A permanent hint is brittle: it hides schema and index changes and can become the worst plan after data grows. Add or adjust the index so the planner chooses well on its own, then remove the hint. Reserve hints for a deliberate, documented exception.
Worked scenario
The hint forces a compound index and the plan is compared.
db.orders
.find({ customerId: 42, status: 'open' })
.hint({ customerId: 1, status: 1 })
.explain('executionStats');Walk through the example
Forcing the { customerId, status } index lets you see whether it examines fewer keys and documents than the planner’s choice. If the forced plan is clearly better, the fix is often to drop a competing index or refresh statistics so the planner picks it. The hint is the experiment, not the solution.
Common mistake
Adding a permanent hint to production because it helped once, which freezes a decision the planner should make and can backfire as data changes. Another is hinting without reading explain, which gives no evidence the forced index is better.
Verify the behavior
Compare explain output with and without the hint, focusing on documents examined and execution time. After adjusting indexes, remove the hint and confirm the planner now chooses the good index by itself.
Interview exercise
Why is a permanent hint risky?
Answer and reasoning
It overrides the planner permanently, so a plan that was optimal at one data size can become the worst choice as data grows or indexes change. It also hides the underlying cause, such as a missing index or stale statistics. Fix the cause and let the planner adapt; keep hints only as a documented, temporary measure.
Continue learning
Compare index design in Compound indexes and diagnostics in Explain diagnostics. Read the MongoDB cursor.hint documentation and try the MongoDB interview questions.