Mongodb使用WiredTiger扫描整个索引，速度非常慢

我有一个设置了以下索引的设备集合：

{
  "v" : 1,
  "key" :
  { "sdk.id" : 1, 
    "sdk.createdAt" : 1, 
    "sdk.updatedAt" : 1, 
    "deviceInfo.isTablet" : 1 },
  "name" : "sdk.id_1_sdk.createdAt_1_sdk.updatedAt_1_deviceInfo.isTablet_1",
  "ns" : "company.Device"
}

我的文件如下：

{
   _id: ObjectId("something"),
   property: 'abcd',
   sdk: [
      { id: 'ab', createdAt: new Date(), updatedAt: new Date()},
      { id: 'ac', createdAt: new Date(), updatedAt: new Date()},
   ]
}

当我执行

db.Device.explain（1）.find（{'sdk.id'：'ab'}）.count（）

时，我得到：

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "company.Device",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "sdk.id" : {
                "$eq" : "ab"
            }
        },
        "winningPlan" : {
            "stage" : "COUNT",
            "inputStage" : {
                "stage" : "COUNT_SCAN",
                "keyPattern" : {
                    "sdk.id" : 1,
                    "sdk.createdAt" : 1,
                    "sdk.updatedAt" : 1,
                    "deviceInfo.isTablet" : 1
                },
                "indexName" : "sdk.id_1_sdk.createdAt_1_sdk.updatedAt_1_deviceInfo.isTablet_1",
                "isMultiKey" : true
            }
        },
        "rejectedPlans" : [ ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 0,
        "executionTimeMillis" : 712,
        "totalKeysExamined" : 569865,
        "totalDocsExamined" : 0,
        "executionStages" : {
            "stage" : "COUNT",
            "nReturned" : 0,
            "executionTimeMillisEstimate" : 636,
            "works" : 569865,
            "advanced" : 0,
            "needTime" : 569864,
            "needFetch" : 0,
            "saveState" : 4452,
            "restoreState" : 4452,
            "isEOF" : 1,
            "invalidates" : 0,
            "nCounted" : 569863,
            "nSkipped" : 0,
            "inputStage" : {
                "stage" : "COUNT_SCAN",
                "nReturned" : 569863,
                "executionTimeMillisEstimate" : 616,
                "works" : 569864,
                "advanced" : 569863,
                "needTime" : 1,
                "needFetch" : 0,
                "saveState" : 4452,
                "restoreState" : 4452,
                "isEOF" : 1,
                "invalidates" : 0,
                "keysExamined" : 569865,
                "keyPattern" : {
                    "sdk.id" : 1,
                    "sdk.createdAt" : 1,
                    "sdk.updatedAt" : 1,
                    "deviceInfo.isTablet" : 1
                },
                "indexName" : "sdk.id_1_sdk.createdAt_1_sdk.updatedAt_1_deviceInfo.isTablet_1",
                "isMultiKey" : true
            }
        },
        "allPlansExecution" : [ ]
    },
    "serverInfo" : {
        "host" : "rs-primary",
        "port" : 27000,
        "version" : "3.0.2",
        "gitVersion" : "6201872043ecbbc0a4cc169b5482dcf385fc464f"
    },
    "ok" : 1
}

正如您所看到的，请求非常慢，而且它只是在我们切换到WiredTiger（之前是这样）之后出现的

该集合包含约60万个文档，其中约55万个文档具有

sdk.id

$eq ab

有人能给我解释一下上面的解释吗？我找不到有关isEOF、saveState和restoreState的任何信息

---

感谢

isEOF：指定执行阶段是否已到达流的末尾

保存状态和恢复状态：在Mongo 3.0中，这些是查询阶段产生（保存状态）然后恢复（恢复状态）的次数计数器。例如，收集扫描（COLLSCAN）阶段可能需要生成以获取尚未在内存中的文档。查询也会产生错误，因此它们可以与其他查询交错，并通过$maxtimms或kill操作安全地停止

这些数字本身并不是很有趣。如果对同一查询运行多个连续解释，您将注意到数字会根据当时的其他操作以及当时是否所有必需的文档都在内存中而发生变化