Most MongoDB performance work is not exotic. It is the same handful of moves, in roughly the same order, applied where the numbers point. Before you reach for a bigger cluster or a shard key, walk this checklist. The scaling meeting cancels itself more often than anyone admits, usually around step two.
The one rule that runs through all of it: measure, do not guess. Every step below produces a number, and the number tells you whether the next step is worth doing.
1. Find the slow queries
You cannot fix what you have not found. The database profiler and the slow query log tell you exactly which operations are slow, ranked, so you are not guessing from the application code. Turn on the profiler, sort system.profile by millis, and you have a worklist, worst first. The full how-to is finding slow queries in MongoDB.
2. Read the plan and fix the index
Take the worst offender and run explain("executionStats"). A COLLSCAN with totalDocsExamined far above nReturned is the classic tell: a query reading the whole collection for want of an index. Add the index it needs, usually a compound index ordered Equality, Sort, Range, and the scan becomes a lookup. This single step fixes the majority of MongoDB slowness. The walk-through is why your MongoDB query is slow.
3. Prune the indexes nothing uses
Optimization is not only adding indexes; it is removing the ones that cost writes and return nothing. Run $indexStats, find the indexes sitting at zero uses across a full traffic cycle, and drop them. Every index you keep is a tax on every insert and update, so the target is the smallest set that covers your queries, which is the whole idea behind index optimization.
4. Filter aggregations early
Aggregation pipelines go slow when they do the expensive work before the cheap work: scanning the whole collection, then filtering. Move $match and $sort to the front so they can use an index, index the $lookup foreign field, and watch the 100MB sort limit. The details are in aggregation performance.
5. Model the schema for your reads
Some performance problems are not indexes at all; they are a schema fighting your access patterns. Embedding data you read together saves a join; referencing data that is large or shared keeps documents lean; the design patterns (attribute, bucket, computed) solve the recurring cases. Start from how to design a MongoDB schema, and catch the drift that quietly breaks queries after the fact.
6. Reclaim the storage
Performance and storage are cousins: a collection that is mostly dead weight is slower to scan and more expensive to hold. Understand storageSize versus your live data, expire old documents with a TTL index, and reclaim space with compact. The full version is storage optimization.
Then measure again
Re-run the profiler. The list is shorter. Re-run explain() on what you fixed; the COLLSCAN is an IXSCAN now, and the examined-to-returned ratio is close to one. If a change did not move the numbers, it did not help, and it is better to know that than to stack another guess on top. That is the whole loop: find, fix, measure, repeat.
Or run the scan
mongoui's Smart Scan runs this checklist in one pass: it surfaces the slow queries and the missing indexes behind them, flags the indexes nothing uses, shows where storage went and what is reclaimable, and reports schema drift, all read straight from your database. Its Query Optimizer reads each plan and names the index that fixes it. Full documents and MongoDB credentials stay local. Local narration makes no provider call; explicit AI narration sends the authored query and bounded structural plan context directly to your selected provider. The checklist is the method; the scan is the same method with the tedium removed. Either way, measure, do not guess.