ตัวดำเนินการตรรกะ: $and, $or, $nor, $not

Most query filters involve conditions on multiple fields, and not all of them should be combined with a simple AND. Sometimes you want documents that meet any of several conditions, or you want to exclude documents matching a pattern. MongoDB's logical operators—$and, $or, $nor, and $not—give you full boolean control over your filter conditions.

Understanding when to use each operator—and knowing the implicit AND shortcut—makes your queries more readable and performant.

When you list multiple field conditions in a single filter object, MongoDB applies them as an implicit AND—all conditions must be true for a document to match. This is the default and most common case.

The implicit AND is both more concise and slightly more efficient than the explicit $and operator because MongoDB can optimize field-level conditions independently. Use implicit AND whenever your conditions target different fields with no ambiguity.

Explicit $and is required in one specific situation: when you need to apply multiple conditions to the same field using different operators, and you cannot express them in a single object (because JavaScript objects cannot have duplicate keys).

The most common case is combining two $or conditions that both reference the field. However, range conditions on a single field ({ price: { $gte: 20, $lte: 100 } }) work fine in one object—explicit $and is only needed when the expressions cannot be combined into one field value.

$or takes an array of filter conditions and matches documents where at least one of the conditions is true. It is the MongoDB equivalent of SQL's OR keyword.

Use $or when you have alternative paths to the same result—for example, finding users who are either admins or have been active in the last 30 days. One important performance note: if each condition is indexed separately, MongoDB can use index union to satisfy the query—but a single compound index covering all conditions is often faster.

$nor matches documents where none of the given conditions is true—it is the complement of $or. A document must fail ALL conditions in the $nor array to be returned.

$nor is less common than $or but useful for exclusion logic: 'find products that are neither discontinued nor out of stock nor in the archived category.' It also matches documents where the queried fields are absent, since absent fields do not match any positive condition.

$not inverts the result of a single field-level operator expression. Unlike $nor (which takes an array of full filter conditions), $not wraps a single operator or regex: { price: { $not: { $gt: 100 } } }.

$not also matches documents where the field does not exist. It is often redundant with $ne or $nin, but is specifically useful for negating regular expressions: { name: { $not: /^admin/i } }—there is no $ne equivalent for regex patterns.

Logical operators can be nested to express arbitrarily complex boolean logic. Think of building a logic tree: outer $and conditions are connected at the top level, and $or sub-expressions express alternatives within a branch.

Complex nested boolean queries can be hard to read—consider breaking them into named JavaScript variables or building the filter object programmatically from user input, rather than nesting them five levels deep in one object literal.

$or queries have specific index usage behavior. MongoDB evaluates each branch of $or independently and merges results:

• If each branch can use an index, MongoDB performs an index union—efficient
• If any branch cannot use an index, MongoDB falls back to a collection scan for that branch—potentially slow

For best performance, ensure every branch of $or has a matching index. When $or conditions can be rewritten as $in on the same field ({ status: { $in: ['a','b'] } }), do so—$in is more efficient than a two-branch $or on the same field.

In aggregation pipeline stages like $match, the same logical operators work exactly as they do in find(). Place $match with your logical conditions as early as possible in the pipeline to reduce the number of documents processed by subsequent stages.

Inside pipeline expression operators (like $project or $addFields), logical operators have a slightly different syntax: { $and: [expr1, expr2] } as expression operators rather than query operators. The query ($match) and expression ($project) contexts use the same operator names but different syntaxes.

In real applications, query filters are often built dynamically from user input (search forms, API query params). Build the filter object programmatically and only add conditions when the parameter is provided—do not add an $or: [] with empty arrays, which would match nothing.

Validate and sanitize all user-provided values before including them in a query. Never pass raw user strings directly to $regex without escaping—an attacker could inject a catastrophically slow regex pattern (ReDoS attack).

MongoDB evaluates logical operator expressions but does NOT necessarily short-circuit like JavaScript. The query planner may reorder conditions for efficiency—for example, moving a condition that uses an index before one that does not, regardless of their order in the query document.

One important implication: in , if the first branch causes a full collection scan, the entire query may scan the collection even if the second branch is efficiently indexed. This is why ensuring every branch of is indexed is so critical for performance. Use explain() to verify the execution plan matches your expectations.

In this lesson you learned: implicit AND is the default when listing multiple fields in one filter object—explicit $and is only needed when you cannot express conditions as unique keys (e.g., two $or blocks), $or matches any one condition and uses index union when each branch is indexed, and $not inverts a single operator and is especially useful for negating regex patterns where $ne does not apply. Next up we explore element operators like $exists and $type for handling optional and mixed-type fields.