这里的基本概念是查找不在每个数组元素的可能值列表中的内容,然后“排除”该文档。这意味着使用$elemMatch 和$nin 作为列表并使用$not 来反转逻辑:
db.collection.find({
"arrayProperty": {
"$not": { "$elemMatch": { "$nin": ["1", "2", "3", "4"] } }
}
})
返回正确的文档:
{ "_id" : "1", "arrayProperty" : [ "1", "2" ] }
{ "_id" : "2", "arrayProperty" : [ "1", "4" ] }
这实际上使用native operators in the "query engine" 来评估表达式,而不是"forced calculation" 通过$expr 或$where,我们将在后面提到。这是正确的结果,但这里唯一的问题是运算符模式实际上否定了任何索引的使用。幸运的是,我们可以做一些事情:
db.collection.find({
"arrayProperty": {
"$in": ["1", "2", "3", "4"],
"$not": { "$elemMatch": { "$nin": ["1", "2", "3", "4"] } }
}
})
虽然一开始看起来有点好笑,但在此处添加 $in 是一个有效条件。它对查询的作用是强制索引实际用于选择有效文档。在仍然是“所有”文档的问题示例中,但在现实世界中,并非所有事物通常都与参数列表匹配。
本质上它改变了解析后的查询条件:
"winningPlan" : { "stage" : "COLLSCAN"
到这里:
"winningPlan" : { "stage" : "FETCH",
"inputStage" : { "stage" : "IXSCAN",
这使得$in 成为值得添加到表达式的过滤器,而“本机查询 运算符”表达式是执行此操作的最快方法。
$expr 的问题(除了只能从 MongoDB 3.6 获得)是它意味着需要扫描“整个集合”才能应用它包含的“聚合运算符表达式”。当然,我们也刚刚了解了$in 在查询中添加了什么
db.collection.find({
"arrayProperty": { "$in": ["1", "2", "3", "4"] },
"$expr": { "$setIsSubset": ["$arrayProperty", ["1", "2", "3", "4"]] }
})
这有一个类似的IXSCAN 输入,其中存在索引,因为$in 并且仅使用$setIsSubset 布尔条件来拒绝在索引选择中找到的其他文档。
早期 MongoDB 版本的使用形式不太理想:
db.collection.aggregate([
{ "$match": { "$in": ["1", "2", "3", "4"] } },
{ "$redact": {
"if": { "$setIsSubset": ["$arrayProperty", ["1", "2", "3", "4"]] },
"then": "$$KEEP",
"else": "$$PRUNE"
}}
])
或者使用$where:
db.collection.find({
"arrayProperty": { "$in": ["1", "2", "3", "4"] },
"$where": function() {
return this.arrayProperty.every(a => ["1", "2", "3", "4"].some(s => a === s))
}
})
所以实际上所有工作都完成了,但 $elemMatch 与 $nin 和 $not 的组合,还包括用于索引选择的 $in 运算符实际上是您真正想要的。所有版本也都支持它。