According to Mongo Documentation,
The
{ item : null }
query matches documents that either contain theitem
field whose value i
The semantics for a null equality match predicate (e.g. {"a.b": null}
) are complicated enough because a field could contain subdocuments that an index scan alone isn't enough to provide the correct result.
According to https://jira.mongodb.org/browse/SERVER-18653?focusedCommentId=931817&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-931817,
Version 2.6.0 of the server changed the semantics of a null equality match predicate, such that the document {a: []} was no longer considered a match for the query predicate {"a.b": null} (in prior versions of the server, this document was considered a match for this predicate). This is documented in the 2.6 compatibility notes, under the "null comparison" section.
For an index with key pattern {"a.b": 1}, this document {a: []} generates the index key {"": null}. Other documents like {a: null} and the empty document {} also generate the index key {"": null}. As a result, if a query with predicate {"a.b": null} uses this index, the query system cannot tell just from the index key {"": null} whether or not the associated document matches the predicate. As a result, INEXACT_FETCH bounds are assigned instead of EXACT bounds, and hence a FETCH stage is added to the query execution tree.
Additional explanation:
- The document {} generates the index key {"": null} for the index with key pattern {"a.b": 1}.
- The document {a: []} also generates the index key {"": null} for the index with key pattern {"a.b": 1}.
- The document {} matches the query {"a.b": null}.
- The document {a: []} does not match the query {"a.b": null}.
Therefore, a query {"a.b": null} that is answered by an index with key pattern {"a.b": 1} must fetch the document and re-check the predicate, in order to ensure that the document {} is included in the result set and that the document {a: []} is not included in the result set.