mongodb - Mongo 三重复合指数

Question

如果你有一个双复合索引 {a : 1, b : 1}，对我来说，如果你单独查询 b 就不会使用索引(即你不能在您的查询中“跳过”a)。但是，如果您单独查询 a，则会使用该索引。

但是，给定一个三重复合索引 { a : 1, b: 1, c: 1} 我的解释命令显示当您在 a 和 c 上查询时使用该索引(即您可以在查询中“跳过”b)。

Mongo 如何在 ac 的查询中使用 abc 索引，在这种情况下该索引的效率如何？

背景:

我的用例是，有时我想查询 a、b、c，有时我想查询 a、c。现在我应该只在 a、b、c 上创建 1 个索引，还是应该在 a、c 上创建一个，在 a、b、c 上创建一个？

(在a,c,b上创建索引没有意义，因为c是多键索引，选择性好。)

Answer 1

bottom line/tl;dr: 如果 a 和 c 是，索引 b 可以被“跳过”查询是否相等，但不是，例如，c 上的排序。

这是一个很好的问题。不幸的是，我找不到任何可以更详细地权威地回答这个问题的内容。我相信此类查询的性能在过去几年中有所提高，因此我不会相信有关该主题的旧资料。

整个事情非常复杂，因为它取决于索引的选择性以及您是否查询相等、不等和/或排序，所以 explain() 是您唯一的 friend ，但这里有我发现的一些东西:

警告:现在出现的是实验结果、推理和猜测的混合体。我可能把 Kyle 的类比延伸得太远了，我什至可能完全错了(而且很不幸，因为我的测试结果与我的推理大致相符)。

很明显可以使用A的索引，这取决于A的选择性，肯定是很有帮助的。 “跳过”B 可能会很棘手，也可能不会。让我们保持它类似于 Kyle's cookbook example :

French
    Beef
        ...
    Chicken
        Coq au Vin
        Roasted Chicken
    Lamb
        ...
    ...

如果你现在要我找一些叫做“Chateaubriand”的法国菜，我可以使用索引 A 并且因为我不知道成分，所以必须扫描 中的所有菜>一个。另一方面，我确实知道每个类别中的菜肴列表是通过索引 C 排序的，因此我只需在每个类别中查找以“Cha”开头的字符串成分表。如果有 50 种成分，我将需要 50 次查找而不是一次查找，但这比必须扫描每道法国菜要好得多!

In my experiments, the number was a lot smaller than the number of distinct values in b: it never seemd to exceed 2. However, I tested this only with a single collection, and it probably has to do with the selectivity of the b-index.

不过，如果你要我给你一份按字母顺序排列的所有法国菜的 list ，我会遇到麻烦。现在 C 上的索引毫无值(value)，我必须对所有这些索引列表进行合并排序。为此，我必须扫描每个元素。

这反射(reflect)在我的测试中。下面是一些简化的结果。原始集合有日期时间、整数和字符串，但我想保持简单，所以现在都是整数。

基本上，只有两类查询:nscanned <= 2 * limit 的查询，以及必须扫描整个集合(120k 文档)的查询。索引是{a, b, c}:

// fast (range query on c while skipping b)
> db.Test.find({"a" : 43, "c" : { $lte : 45454 }});
// slow (sorting)
> db.Test.find({"a" : 43, "c" : { $lte : 45454 }}).sort({ "c" : -1});
> db.Test.find({"a" : 43, "c" : { $lte : 45454 }}).sort({ "b" : -1}); 

// fast (can sort on c if b included in the query)
> db.Test.find({"a" : 43, "b" : 7887, "c" : { $lte : 45454 }}).sort({ "c" : -1});

// fast (older tutorials claim this is slow)
> db.Test.find({"a" : {$gte : 43}, "c" : { $lte : 45454 }});

您的里程会有所不同。