C100DBA · Question #117
Consider the following example document: { "_id": Objectld("5360c0a0a655a60674680bbe"), "user" "login": "irOn" "description": "Made of steel" "date": ISODate("2014-04-30T09:16:45.836Z"), } > and…
The correct answer is B. As an indexed query using "mylndex" because field "user.login" is indexed. Option B is correct because "user.login" is the leading field in myIndex, and the query filters on that exact field using a regex. MongoDB can use the index to locate matching documents without scanning the entire collection, making this a valid indexed query. Option A is wrong…
Question
Consider the following example document:
{ "_id": Objectld("5360c0a0a655a60674680bbe"), "user" "login": "irOn" "description": "Made of steel" "date": ISODate("2014-04-30T09:16:45.836Z"), } > and index creation command:
db.users.createlndex( { "user.login": 1, "user.date": -1 }, "mylndex" ) When performing the following query:
db.users.find( { "user.login": /Air.*/ }, { "user":1, "_id":0 > ).sort( { "user.date":1 > ) which of the following statements correctly describe how MongoDB will handle the query? Check all that apply.
Options
- AAs an optimized sort query (scanAndOrder = false) using "mylndex" because we are sorting on an
- BAs an indexed query using "mylndex" because field "user.login" is indexed
- CMongoDB will need to do a table/collection scan to find matching documents
- DNone of the above
- EAs a covered query using "mylndex" because we are filtering out "_id" and only returning
How the community answered
(61 responses)- A3% (2)
- B46% (28)
- C8% (5)
- D15% (9)
- E28% (17)
Explanation
Option B is correct because "user.login" is the leading field in myIndex, and the query filters on that exact field using a regex. MongoDB can use the index to locate matching documents without scanning the entire collection, making this a valid indexed query.
Option A is wrong because an optimized sort (scanAndOrder = false) requires the sort field to be the next field in the index after an equality match on the prefix. Here, the filter on "user.login" uses a regex (a range-type operation, not equality), so after that range scan the "user.date" values are not globally ordered - MongoDB must still perform an in-memory sort. The sort direction mismatch (index: -1, query: 1) further prevents index-assisted sorting.
Option C is wrong because MongoDB can use myIndex on "user.login" to avoid a full collection scan - the index narrows down candidates before checking documents.
Option E is wrong because a covered query requires the index to contain every field returned by the projection. The projection {"user": 1} returns all of user's subfields, including "user.description", which is not in the index - so MongoDB must fetch the raw documents, disqualifying it as covered.
Memory tip: Think of covered = "index has everything," optimized sort = "equality match first, then range/sort on next index field." A regex is a range, not an equality - it breaks the sort optimization chain.
Topics
Community Discussion
No community discussion yet for this question.