当前位置: 首页 > 知识库问答 >
问题:

mongodb--count()比find()慢得多?

乐正晟
2023-03-14

我正在使用mongoose来计算匹配某个查询的文档数量。此查询的索引为:{createdat:-1,status:-1,oid:-1}

Mongo版本为3.2,收藏文档数量约为175万。

model.find({
                        createdAt: {'$gte': threeMonths, '$lt': today},
                        status: {'$in': model.STATUS_SET}
                    }).select({_id: 0, status: 1}).count().then((c) => result[alias] = c)

需要2分多钟。但如果我这么做了:

model.find({
                createdAt: {'$gte': threeMonths, '$lt': today},
                status: {'$in': model.STATUS_SET}
            }).select({_id: 0, status: 1}).lean().then((c) => result[alias] = c.length)

然后大约需要2.5秒。

我做错什么了吗?我能做些什么来加快速度吗?

编辑:解释日志。

计数:

"executionStats" : {
		"executionSuccess" : true,
		"nReturned" : 0,
		"executionTimeMillis" : 82671,
		"totalKeysExamined" : 1749689,
		"totalDocsExamined" : 1643722,
		"executionStages" : {
			"stage" : "COUNT",
			"nReturned" : 0,
			"executionTimeMillisEstimate" : 80960,
			"works" : 1750066,
			"advanced" : 0,
			"needTime" : 1749689,
			"needFetch" : 376,
			"saveState" : 14662,
			"restoreState" : 14662,
			"isEOF" : 1,
			"invalidates" : 0,
			"nCounted" : 1643722,
			"nSkipped" : 0,
			"inputStage" : {
				"stage" : "FETCH",
				"nReturned" : 1643722,
				"executionTimeMillisEstimate" : 80890,
				"works" : 1750065,
				"advanced" : 1643722,
				"needTime" : 105967,
				"needFetch" : 376,
				"saveState" : 14662,
				"restoreState" : 14662,
				"isEOF" : 1,
				"invalidates" : 0,
				"docsExamined" : 1643722,
				"alreadyHasObj" : 0,
				"inputStage" : {
					"stage" : "IXSCAN",
					"nReturned" : 1643722,
					"executionTimeMillisEstimate" : 3800,
					"works" : 1749689,
					"advanced" : 1643722,
					"needTime" : 105967,
					"needFetch" : 0,
					"saveState" : 14662,
					"restoreState" : 14662,
					"isEOF" : 1,
					"invalidates" : 0,
					"keyPattern" : {
						"createdAt" : -1,
						"status" : -1,
						"oId" : -1
					},
					"indexName" : "moderatedContent",
					"isMultiKey" : false,
					"direction" : "forward",
					"indexBounds" : {
						"createdAt" : [
							"(new Date(1467195213000), new Date(1459246413000)]"
						],
						"status" : [
							"[\"UNDECIDED\", \"UNDECIDED\"]",
							"[\"APPROVED\", \"APPROVED\"]"
						],
						"oId" : [
							"[MaxKey, MinKey]"
						]
					},
					"keysExamined" : 1749689,
					"dupsTested" : 0,
					"dupsDropped" : 0,
					"seenInvalidated" : 0,
					"matchTested" : 0
				}
			}
		},
		"allPlansExecution" : [ ]
	}

为了找到。

"executionStats" : {
		"executionSuccess" : true,
		"nReturned" : 1643722,
		"executionTimeMillis" : 1216,
		"totalKeysExamined" : 1749689,
		"totalDocsExamined" : 0,
		"executionStages" : {
			"stage" : "PROJECTION",
			"nReturned" : 1643722,
			"executionTimeMillisEstimate" : 1080,
			"works" : 1749690,
			"advanced" : 1643722,
			"needTime" : 105967,
			"needFetch" : 0,
			"saveState" : 13669,
			"restoreState" : 13669,
			"isEOF" : 1,
			"invalidates" : 0,
			"transformBy" : {
				"_id" : 0,
				"status" : 1
			},
			"inputStage" : {
				"stage" : "IXSCAN",
				"nReturned" : 1643722,
				"executionTimeMillisEstimate" : 920,
				"works" : 1749690,
				"advanced" : 1643722,
				"needTime" : 105967,
				"needFetch" : 0,
				"saveState" : 13669,
				"restoreState" : 13669,
				"isEOF" : 1,
				"invalidates" : 0,
				"keyPattern" : {
					"createdAt" : -1,
					"status" : -1,
					"oId" : -1
				},
				"indexName" : "moderatedContent",
				"isMultiKey" : false,
				"direction" : "forward",
				"indexBounds" : {
					"createdAt" : [
						"(new Date(1467195213000), new Date(1459246413000)]"
					],
					"status" : [
						"[\"UNDECIDED\", \"UNDECIDED\"]",
						"[\"APPROVED\", \"APPROVED\"]"
					],
					"oId" : [
						"[MaxKey, MinKey]"
					]
				},
				"keysExamined" : 1749689,
				"dupsTested" : 0,
				"dupsDropped" : 0,
				"seenInvalidated" : 0,
				"matchTested" : 0
			}
		}
	}
"executionStats" : {
		"executionSuccess" : true,
		"nReturned" : 0,
		"executionTimeMillis" : 89191,
		"totalKeysExamined" : 1749689,
		"totalDocsExamined" : 1643722,
		"executionStages" : {
			"stage" : "COUNT",
			"nReturned" : 0,
			"executionTimeMillisEstimate" : 83400,
			"works" : 1751709,
			"advanced" : 0,
			"needTime" : 1749689,
			"needFetch" : 2019,
			"saveState" : 15648,
			"restoreState" : 15648,
			"isEOF" : 1,
			"invalidates" : 0,
			"nCounted" : 1643722,
			"nSkipped" : 0,
			"inputStage" : {
				"stage" : "FETCH",
				"nReturned" : 1643722,
				"executionTimeMillisEstimate" : 83260,
				"works" : 1751708,
				"advanced" : 1643722,
				"needTime" : 105967,
				"needFetch" : 2019,
				"saveState" : 15648,
				"restoreState" : 15648,
				"isEOF" : 1,
				"invalidates" : 0,
				"docsExamined" : 1643722,
				"alreadyHasObj" : 0,
				"inputStage" : {
					"stage" : "IXSCAN",
					"nReturned" : 1643722,
					"executionTimeMillisEstimate" : 8290,
					"works" : 1749689,
					"advanced" : 1643722,
					"needTime" : 105967,
					"needFetch" : 0,
					"saveState" : 15648,
					"restoreState" : 15648,
					"isEOF" : 1,
					"invalidates" : 0,
					"keyPattern" : {
						"createdAt" : -1,
						"status" : -1,
						"oId" : -1
					},
					"indexName" : "moderatedContent",
					"isMultiKey" : false,
					"direction" : "forward",
					"indexBounds" : {
						"createdAt" : [
							"(new Date(1467195213000), new Date(1459246413000)]"
						],
						"status" : [
							"[\"UNDECIDED\", \"UNDECIDED\"]",
							"[\"APPROVED\", \"APPROVED\"]"
						],
						"oId" : [
							"[MaxKey, MinKey]"
						]
					},
					"keysExamined" : 1749689,
					"dupsTested" : 0,
					"dupsDropped" : 0,
					"seenInvalidated" : 0,
					"matchTested" : 0
				}
			}
		}
	}

共有1个答案

冯玮
2023-03-14

你答案的关键是

//count
"totalDocsExamined" : 1643722,

VS

//find
"totalDocsExamined" : 0,

find查询完全对索引进行操作,不读取任何单个文档,而count查询实际上读取数据库中的每个文档。

除此之外,在精益查找查询中,只有select()ingidstatus,这似乎是投影的(“transformby”...),因此整个查询成为一个覆盖查询,不需要读取任何文档来为请求服务。

 类似资料:
  • 问题内容: 我有一个简单的任务:计算每个字母在一个字符串中出现的次数。我已经使用了它,但是在一个论坛上我看到了使用/比每个字母都要慢得多的信息。我认为它只能在字符串中进行一次遍历,而解决方案则必须遍历该字符串四次(在这种情况下)。为什么这么慢? 问题答案: 允许您计算任何可哈希对象,而不仅仅是子字符串。两种解决方案都是-time。您的测量结果表明,迭代和散列单个字符的开销大于运行4倍。 可以 使用

  • 我刚刚实现了基本的opengl渲染到我的pyplay应用程序中,认为硬件加速会使程序运行得更快。相反,它要慢得多。 看起来问题是绘图功能。 这是我的opengl绘图功能 我的分析器为draw函数提供了什么 我的分析器文本的其余部分:(1个月后到期) http://pastebin.com/ApfiCQzw 我的源代码 https://bitbucket.org/claysmithr/warbots

  • 问题内容: 我正在重写我的一个Android应用程序以利用NDK,并且它每次要做的第一件事之一是打开一个1.5MB的文本文件(大约15万行),并将每一行放入数据中结构体。当我使用Java的BufferedReader.readLine()进行此操作时,从SD卡读取文件大约需要2.5秒。这是我用于此的代码: 将C 与ifstream一起使用需要更长的时间…对于同一文件大约需要3分钟。这是我在C 中使

  • 问题内容: 我正在使用bigquery.go库。 在调查某些性能时,我发现我的导出(从.csv到GCS)作业(仅导出作业)从客户端启动平均需要60秒,而从WebGUI启动的同一作业大约需要20秒。这可能是什么原因? 代码如下: 问题答案: WEB UI通常具有轮询机制来检查作业何时完成,因此您可能会看到更长的时间。通常,导出到GCS的文件在WebUI中显示的时间早于作业实际完成的时间。 为了确保并

  • 下面的代码将简单的值持有者映射到一个对象,它在Java中的运行速度比使用XCode 7 beta3“最快、积极的优化[-ofast]”的Objective-C快15倍以上。在Java中,我可以获得超过280m/sec的查找,但在objc示例中只有大约19m。(我在这里发布了相应的Java代码,因为这是作为一个Swift比较开始的:Swift Dictionary即使经过优化也很慢:是否不断保留/发