Query Language

What we're doing: Show that a scalar filter against an array field matches on "any element," which surprises readers expecting exact-value semantics.

db.products.insertOne({ name: "Tee", tags: ["clothing", "sale", "summer"] })

db.products.find({ tags: "sale" })
// -> matches the document above, even though tags is a 3-element array, not the scalar "sale"

1

tags is an array field with three string elements.

4

A scalar equality filter on an array field matches if any element equals it — no $elemMatch or index needed for this simple case.

Why this works: This "any element" behavior is what makes tag-style array fields queryable without extra syntax — but it also means { tags: "sale" } and { tags: ["sale"] } mean different things: the first matches "sale" anywhere in the array, the second requires the array to be exactly that one-element array.

What we're doing: Show $in replacing a longer $or, and that $in and $nin take an array, not a bare value.

// Equivalent to: db.orders.find({ $or: [ { status: "pending" }, { status: "shipped" } ] })
db.orders.find({ status: { $in: ["pending", "shipped"] } })

db.orders.find({ status: { $nin: ["cancelled", "refunded"] } })
// -> matches every status except the two listed

1

$in on one field is a shorter, equivalent form of an $or across repeated equality checks on that same field.

4

$nin is the negation — matches documents where the field is none of the listed values.

Why this works: $in reads more directly than an equivalent $or once there are three or more alternatives, and it is the natural fit when the list of values is already an array from elsewhere in the code (e.g. a set of selected checkboxes).

What we're doing: Show why $and is sometimes required even though a plain object is already an implicit AND.

// WRONG: a JS object cannot repeat the key "price" twice
// db.products.find({ price: { $gt: 10 }, price: { $lt: 50 } })

db.products.find({ $and: [ { price: { $gt: 10 } }, { price: { $lt: 50 } } ] })
// -> both conditions on price are kept, because each lives in its own list entry

2

A plain object cannot express two separate operator conditions on the same field — the second "price" key would silently overwrite the first.

5

Explicit $and gives each condition its own object, so repeated fields with different operators do not collide.

Why this works: MongoDB actually allows { price: { $gt: 10, $lt: 50 } } as one combined operator document for this specific case (both operators on one field), so $and is not strictly needed here — but it becomes necessary the moment the same operator needs to appear twice, or the conditions need to nest with $or.

What we're doing: Show $type catching a schema-flexibility bug: some documents stored price as a string instead of a number.

db.products.insertMany([
  { name: "Mug", price: 12.99 },
  { name: "Pen", price: "9.99" },  // inserted by a buggy import script — a string, not a number
])

db.products.find({ price: { $type: "string" } })
// -> finds the "Pen" document, the one with the wrong type

1

A schema-flexible collection allows this without any error — both documents insert successfully.

4

$type: "string" finds exactly the documents where price accidentally became a string.

Why this works: Because MongoDB does not enforce a field's type by default, a bug in an import script or a client library can silently store the "wrong" BSON type in some documents. $type is the query-time tool for auditing a collection for that kind of drift.

What we're doing: Show $elemMatch preventing a cross-element false match on an array of embedded documents.

db.students.insertOne({
  name: "Alex",
  results: [ { subject: "math", score: 60 }, { subject: "art", score: 95 } ],
})

// WRONG: matches Alex even though no single result is both math AND >= 90
db.students.find({ "results.subject": "math", "results.score": { $gte: 90 } })

// RIGHT: requires one element to satisfy both conditions
db.students.find({ results: { $elemMatch: { subject: "math", score: { $gte: 90 } } } })

6

Two separate dot-notation conditions can each be satisfied by a different array element — math from one, >= 90 from another.

9

$elemMatch requires both conditions to hold for the same element, correctly excluding Alex.

Why this works: Dot-notation conditions on an array of embedded documents are evaluated independently against the whole array, not against "the same element" — this is the single most common array-query mistake, and $elemMatch is the direct fix for it.

What we're doing: Show the same field queried two ways — one usable by an index, one not — and why the difference matters at scale.

db.users.find({ email: { $regex: "^alice" } })
// -> can use an index on email as a range/prefix scan, like a $gte/$lt pair

db.users.find({ email: { $regex: "alice" } })
// -> unanchored: "alice" could be anywhere in the string, so every value must be checked

1

A ^-anchored pattern narrows to a contiguous range of the sorted index, the same way a prefix range query would.

3

Without the anchor, the pattern could match in the middle of any string, so an index cannot rule any value out ahead of time.

Why this works: This is the one regex fact worth memorizing before writing any pattern query against a collection of meaningful size: anchoring at the start is not just a stylistic choice, it is the difference between an index-assisted query and a full collection scan.

What we're doing: Show dot notation reaching into a two-level embedded document, and the quoting requirement that trips up readers coming from plain JS object access.

db.users.insertOne({
  name: "Alan",
  contact: { phone: { type: "cell", number: "111-222-3333" } },
})

// WRONG in a query filter: contact.phone.number is not valid JS/BSON syntax here
// db.users.find({ contact.phone.number: "111-222-3333" })

db.users.find({ "contact.phone.number": "111-222-3333" })
// -> matches, because the whole path is one quoted string key

6

Unquoted dots are not valid object-key syntax in the query document itself — this is a syntax error, not a logic error.

9

The full path must be one quoted string — MongoDB parses the dots internally to walk the nested structure.

Why this works: It is easy to reach for real nested-object syntax ({ contact: { phone: { number: ... } } }) out of habit, but that means something different in a query filter — it would require phone to be *exactly* that one-field object, not just contain that field among others.

What we're doing: Show a query that skips the leading index field and cannot use the index as a narrowing structure.

db.inventory.createIndex({ item: 1, location: 1, stock: 1 })

db.inventory.find({ item: "widget", stock: { $gt: 50 } })
// -> uses the index up to the "item" prefix, then checks stock without index help (partial use)

db.inventory.find({ location: "east", stock: { $gt: 50 } })
// -> cannot use this index efficiently at all — location is not a leading prefix

3

Filtering on item (the leading field) plus stock (the third field, skipping location) still gets partial index help from the item prefix.

6

Filtering on location and stock without item gets none of the index's narrowing benefit — MongoDB falls back to scanning broadly.

Why this works: This is why index field order is a design decision, not an afterthought: it should match the field(s) most queries filter on first, with more selective or more commonly-combined fields earlier in the definition.