不包括 $ne 查询的 mongo count 操作答案

【问题标题】：mongo count operations with $ne query are not covered不包括 $ne 查询的 mongo count 操作
【发布时间】：2016-12-22 03:09:17
【问题描述】：

我正在运行 mongo 3.2.11 (WiredTiger)。我有一个包含 ISODates 字段的集合，我注意到这种形式的查询之间存在显着差异：

db.my_collection.count({ my_field: { $ne: null } })

还有这个表格：

db.my_collection.count({ my_field: { $gt: ISODate('2010-01-01') } })

当我运行解释时，我看到第一种类型的查询产生一个IXSCAN 阶段，第二种类型产生一个COUNT_SCAN 阶段。我的猜测是 COUNT_SCAN 查询被覆盖（因此它们不需要从磁盘获取文档），而 IXSCAN 查询需要从磁盘提取数据。

如果我的理解是正确的，有谁知道为什么{$ne: null} 不能被覆盖？我想了解规则以及它是否可能会改变，因为我一直使用{$ne: null}（当更具体但不太优雅的 IMO 像 {$gt: some_really_early_date} 也可以工作时）。

【问题讨论】：

我只是好奇。尽管不是完全替换，但如果您使用逻辑运算符和 db.my_collection.count({ my_field: { $not: {$type:12 } }}) 代替它会改变什么，而且我很肯定的这个变体 db.my_collection.count({ my_field: { $exists: true}}) 将使用 COUNT_SCAN
@SagarReddy 好问题，我试过$exists: true，但它在查询计划器中显示IXSCAN。我不确定你想用$type: 12 做什么（你的意思是空类型还是日期类型？）
对不起$type: 10。无论如何，我不希望它起作用。它将根据文档进行 IXSCAN。我期待$exists 能够工作。

标签： mongodb indexing

【解决方案1】：

不等式运算符 $ne 的选择性不是很高，因为它通常匹配索引的大部分。因此，在许多情况下，带有索引的 $ne 查询的性能可能不比必须扫描集合中所有文档的 $ne 查询好。

【讨论】：

我认为这与这里无关 - 我上面显示的两种形式的查询在我的情况下都产生相同的计数

【解决方案2】：

$in 也有类似的问题（参见示例）。你可以找到the issue here。

示例（使用IXSCAN 代替COUNT_SCAN）：

collection.count({
  thing: {
    $in: [ // for a single entry it uses COUNT_SCAN
      ObjectId('54e1b392cf53590c4f3dd77c'),
      ObjectId('557ff02b83f641960fef49da')
    ]
  }
})

【讨论】：

【解决方案3】：

简单的答案是：这是一个 mongodb 错误！请参阅以下 JIRA 问题，该问题已于 2015 年创建，但在积压中仍未解决：https://jira.mongodb.org/browse/SERVER-18861

您可以投票支持它最终修复它。

【讨论】：