MongoDB（和 Mongoose.js）：查询条件的顺序重要吗？

在创建一个简单的 MongoDB 查询时，我有一个关于条件排序在查询中 - 例如（Mongoose.js 语法）：

conditions = { archived: false, first_name: "Billy" };

vs.

conditions = { first_name: "Billy", archived: false };

..在一个简单的 find() 函数中：

User.find(conditions, function(err, users) { <some logic> });

..假设一个简单的单键索引策略：

UserSchema.index( { first_name: 1, archived: 1} );

..上面列出的条件的顺序重要吗？

重要的：我知道复合索引的顺序很重要，但根据上面的内容，我对单键索引查询感到好奇。因为我们在这里，所以也对完全非索引查询的情况感兴趣。 :)

另一种解释：换句话说，假设 100Users（50 个已存档，50 个未存档），给出两种可能的内部 MongoDB 搜索策略：

1. 首先过滤掉所有50个archived用户，然后使用以下命令搜索剩余 50 个非存档用户first_name“比利”的价值
2. 首先搜索 ALL 100User的文件first_name值“Billy”，然后通过删除所有已存档的 Billy 来过滤找到的对象。

..我假设#1更快（在具有两个以上条件的大型查询中可能更快）。但无论哪个更快以及为什么，肯定其中之一是更快。

核心问题：在复合索引的广阔而强大的世界之外，MongoDB 是否知道如何自动执行其最高效/快速的搜索/过滤器，无论哪些字段和顺序如何？或者我们是否需要以编程方式告诉系统什么是最好的（通过提供条件的顺序等）？

我对你的问题有点困惑，只是因为你提供的索引（{ first_name: 1, archived: 1 }) is复合索引。以下所有查询都将使用该复合索引：

conditions = { archived: false, first_name: "Billy" };
conditions = { first_name: "Billy", archived: false };
conditions = { first_name: "Billy" };

现在，假设我们有两个独立的索引，{ first_name: 1 } and { archived: 1 }。在这种情况下，MongoDB将进行查询优化来确定哪个索引的使用效率最高。您可以在此处阅读有关 MongoDB 执行的查询优化的更多信息。 http://docs.mongodb.org/manual/core/query-plans/#read-operations-query-optimization

因此，MongoDB 查询优化器可能会为您提供的两个多条件查询使用相同的索引：

conditions = { archived: false, first_name: "Billy" };
conditions = { first_name: "Billy", archived: false };

或者，您可以使用hint http://docs.mongodb.org/manual/reference/method/cursor.hint/强制 MongoDB 使用您选择的索引。一般来说，这是可能不是一个好主意。您还可以手动检查哪个索引对于特定查询最有效详细信息请参见此处 http://docs.mongodb.org/manual/tutorial/analyze-query-plan/#compare-performance-of-indexes.

您可以使用以下命令查看查询正在使用哪个索引.explain() http://docs.mongodb.org/manual/reference/method/cursor.explain/#cursor.explainMongo shell 中的功能。 （如果没有使用索引，你会看到"cursor" : "BasicCursor"在生成的文档中。另一方面，如果使用复合索引，您会看到类似的内容"cursor" : "BtreeCursor first_name_1_archived_1"。如果使用单字段索引之一，您可能会看到"cursor" : "BtreeCursor archived_1".

此外，MongoDB 的搜索策略是这样的：

• 首先，遍历索引，利用索引边界过滤掉尽可能多的文档；
• next, if there are additional predicates that cannot be satisfied using the index,
  • 获取文档，
  • 应用谓词，
  • 并适当地从结果中包含/排除该文档。

查询优化器并行运行所有可能的查询计划并选择“最佳”计划，但是所有查询计划都遵循上述策略。 （BasicCursor 是一种退化情况：它遍历所有文档并将谓词应用于每个文档。）

tl;dr?当谓词以任何顺序出现时，匹配器足够智能来匹配相等谓词。

那有意义吗？