Query patterns that cause collection scans in MongoDB - Time & Space Complexity
When MongoDB runs a query without using an index, it looks at every document in the collection. This is called a collection scan.
We want to understand how the time to run such queries grows as the collection gets bigger.
Analyze the time complexity of the following MongoDB query.
db.products.find({ price: { $gt: 100 } })
This query finds all products with a price greater than 100. Assume there is no index on the price field.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning each document in the collection one by one.
- How many times: Once for every document in the collection.
As the number of documents grows, the query looks at each document once.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 document checks |
| 100 | 100 document checks |
| 1000 | 1000 document checks |
Pattern observation: The work grows directly with the number of documents. Double the documents, double the work.
Time Complexity: O(n)
This means the query time grows in a straight line as the collection size grows.
[X] Wrong: "MongoDB always uses indexes, so query time stays the same no matter how big the collection is."
[OK] Correct: If there is no index on the queried field, MongoDB must check every document, so query time grows with collection size.
Understanding when queries cause collection scans helps you explain performance issues clearly and shows you know how databases work under the hood.
"What if we added an index on the price field? How would the time complexity change?"
Practice
Solution
Step 1: Understand collection scan causes
A collection scan happens when MongoDB must check every document because no index supports the query.Step 2: Analyze query patterns
Querying a field without an index forces MongoDB to scan the entire collection, unlike queries using indexed fields.Final Answer:
Querying a field without an index -> Option AQuick Check:
No index = collection scan [OK]
- Assuming all queries use indexes automatically
- Confusing covered index with collection scan
- Thinking equality queries always cause scans
age?Solution
Step 1: Check query syntax correctness
All queries are syntactically valid, but some use operators that prevent index use.Step 2: Identify index-friendly query
Query with{ age: { $gt: 25 } }uses range operator on indexed field, avoiding collection scan. Queries with$whereor$regexoften cause scans.Final Answer:
db.users.find({ age: { $gt: 25 } }) -> Option AQuick Check:
Range query on indexed field = no scan [OK]
- Using $where causes collection scan
- Assuming $regex always uses index
- Confusing $text search with field index
products with an index on category, what will be the result of this query?db.products.find({ category: { $in: ['electronics', 'books'] } })Solution
Step 1: Understand $in operator with indexes
The $in operator can use indexes on the queried field to find matching values efficiently.Step 2: Analyze query behavior
Sincecategoryis indexed, MongoDB uses the index to find documents where category is 'electronics' or 'books'.Final Answer:
Uses index on category and returns matching documents -> Option DQuick Check:
$in + indexed field = index used [OK]
- Thinking $in disables index use
- Assuming $in causes syntax error
- Believing collection scan always happens
orders with an index on status. Which query will cause a collection scan and how can you fix it?db.orders.find({ $where: 'this.status === "shipped"' })Solution
Step 1: Identify $where impact on query
The $where operator runs JavaScript on each document, forcing a collection scan regardless of indexes.Step 2: Fix query to use index
Replacing $where with a direct field query{ status: 'shipped' }uses the index onstatus, avoiding collection scan.Final Answer:
Causes collection scan; fix by using { status: 'shipped' } -> Option CQuick Check:
$where disables index; direct query fixes [OK]
- Assuming $where uses indexes
- Trying to fix with $regex instead of direct query
- Confusing syntax error with collection scan
users collection:db.users.find({ $or: [ { age: { $gt: 30 } }, { name: /John/ } ] })Given indexes on
age and name, which change will prevent collection scans?Solution
Step 1: Understand $or with mixed operators
Regex queries often prevent index use, causing collection scans even if other fields are indexed.Step 2: Optimize by splitting queries
Running two separate queries--one onageand one onname--each using indexes, then combining results in application avoids scans.Final Answer:
Rewrite query to separate $or into two queries using indexed fields -> Option BQuick Check:
Split queries + indexes avoid scans [OK]
- Believing regex always uses index
- Using $where increases scans
- Removing indexes reduces performance
Ready to prove it?
Pass the test and this pattern moves unknown
