For a query like
{x: {$not: {$in: [["String"]]}}
a collection scan will return the document
{x: "String"}
because "String" != ["String"] and so "String" is not in the array [["String"]]. However, if you build an index on {x: 1} then the above document is not returned. Using explain, you can see the index bounds are:
{ "x" : [ "[MinKey, \"String\")", "(\"String\", [ \"String\" ])", "([ \"String\" ], MaxKey]" ] }
Compare this to what should be the equivalent query
{x: {$ne: ["String"]}}
we then get the bounds:
{ "x" : [ "[MinKey, [ \"String\" ])", "([ \"String\" ], [ [ \"String\" ] ])", "([ [ \"String\" ] ], MaxKey]" ] }
It looks like the index bounds building logic for an $in within a $not.
- causes
-
SERVER-40691 $nin:[[],...] queries are not indexed
- Closed
- related to
-
SERVER-39764 Negation of $in with embedded array can incorrectly plan from the cache, triggering invariant
- Closed