Mongodb 即使使用索引，Mongo查询也需要一段时间

我已经运行mongo测试服务器几个星期了，一切都很顺利。我有一个查询来获取已删除文件的数量，它在1.4亿个文档（44GB的数据）的不到1秒的范围内运行。今天，突然之间，同样的问题需要一段时间。在find查询上运行explain时，它显示它正在使用现有的索引，但仍然需要很长时间。奇怪的是，这并不是唯一一个这样做的查询。如果我运行一个返回1项的查询，它几乎是即时的。当它返回一组文档时，需要花费很多时间（几分钟）。下面是MongoShell的查询和解释输出。我已经删除了被拒绝的计划以节省空间，但如果需要，可以将其放回原处。我是mongo的新手，非常感谢您的帮助。我还有一个查询，我已经等待了24分钟，它只是对一个EventID字段的搜索，该字段是一个索引字段

 db.EventEntries.find({IsDelete:true, TimeCreated:{$gte:ISODate('2017-06-30')}}).explain('executionStats')
{
    "queryPlanner" : {
            "plannerVersion" : 1,
            "namespace" : "Events.EventEntries",
            "indexFilterSet" : false,
            "parsedQuery" : {
                    "$and" : [
                            {
                                    "IsDelete" : {
                                            "$eq" : true
                                    }
                            },
                            {
                                    "TimeCreated" : {
                                            "$gte" : ISODate("2017-06-30T00:00:00Z")
                                    }
                            }
                    ]
            },
            "winningPlan" : {
                    "stage" : "FETCH",
                    "inputStage" : {
                            "stage" : "IXSCAN",
                            "keyPattern" : {
                                    "IsDelete" : 1,
                                    "TimeCreated" : 1
                            },
                            "indexName" : "IsDelete_1_TimeCreated_1",
                            "isMultiKey" : true,
                            "multiKeyPaths" : {
                                    "IsDelete" : [ ],
                                    "TimeCreated" : [
                                            "TimeCreated"
                                    ]
                            },
                            "isUnique" : false,
                            "isSparse" : false,
                            "isPartial" : false,
                            "indexVersion" : 2,
                            "direction" : "forward",
                            "indexBounds" : {
                                    "IsDelete" : [
                                            "[true, true]"
                                    ],
                                    "TimeCreated" : [
                                            "[new Date(1498780800000), new Date(9223372036854775807)]"
                                    ]
                            }
                    }
            },

    },
    "executionStats" : {
            "executionSuccess" : true,
            "nReturned" : 138570,
            "executionTimeMillis" : 177933,
            "totalKeysExamined" : 138570,
            "totalDocsExamined" : 138570,
            "executionStages" : {
                    "stage" : "FETCH",
                    "nReturned" : 138570,
                    "executionTimeMillisEstimate" : 177834,
                    "works" : 138571,
                    "advanced" : 138570,
                    "needTime" : 0,
                    "needYield" : 0,
                    "saveState" : 8887,
                    "restoreState" : 8887,
                    "isEOF" : 1,
                    "invalidates" : 0,
                    "docsExamined" : 138570,
                    "alreadyHasObj" : 0,
                    "inputStage" : {
                            "stage" : "IXSCAN",
                            "nReturned" : 138570,
                            "executionTimeMillisEstimate" : 561,
                            "works" : 138571,
                            "advanced" : 138570,
                            "needTime" : 0,
                            "needYield" : 0,
                            "saveState" : 8887,
                            "restoreState" : 8887,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "keyPattern" : {
                                    "IsDelete" : 1,
                                    "TimeCreated" : 1
                            },
                            "indexName" : "IsDelete_1_TimeCreated_1",
                            "isMultiKey" : true,
                            "multiKeyPaths" : {
                                    "IsDelete" : [ ],
                                    "TimeCreated" : [
                                            "TimeCreated"
                                    ]
                            },
                            "isUnique" : false,
                            "isSparse" : false,
                            "isPartial" : false,
                            "indexVersion" : 2,
                            "direction" : "forward",
                            "indexBounds" : {
                                    "IsDelete" : [
                                            "[true, true]"
                                    ],
                                    "TimeCreated" : [
                                            "[new Date(1498780800000), new Date(9223372036854775807)]"
                                    ]
                            },
                            "keysExamined" : 138570,
                            "seeks" : 1,
                            "dupsTested" : 138570,
                            "dupsDropped" : 0,
                            "seenInvalidated" : 0
                    }
            }
    },
    "serverInfo" : {
            "host" : "",
            "port" : ,
            "version" : "3.4.4",
            "gitVersion" : "888390515874a9debd1b6c5d36559ca86b44babd"
    },
    "ok" : 1

---

}

如果查询单个值的速度快，而查询较大范围的值的速度慢，那么很明显，您可能会受到服务器资源（I/O或RAM）的限制。服务器上有多少RAM，索引有多大？44GB是

dataSize

（实际数据）还是

storageSize

（磁盘大小，可能包括压缩）？在同一MongoDB部署中是否有其他数据库？另外，如果您立即再次运行同一查询，查询需要多长时间才能执行？谢谢您的评论。我重建了索引，但失败了，所以我从头开始。但这可能是内存问题。因为它是一个测试虚拟机，所以它只有3.5 gb的ram。对于您的数据大小和正在运行的范围查询，3.5 gb的总ram听起来很低。检查db.EventEntries.stats（）.totalIndexSize以了解此集合的索引大小。默认情况下，MongoDB 3.4中的WiredTiger将为内部缓存（索引和未压缩数据）分配内存，在您的情况下，该内存大约为750MB。范围查询返回138570个文档，与单个文档的相等查询相比，它会给有限的资源带来更大的压力。