为什么索引方向在MongoDB中很重要？

Question

引用文档：

创建索引时，与键关联的数字指定索引的方向，因此它应该始终为1（升序）或-1（降序）。对于单键索引或随机访问检索，方向无关紧要，但如果您对复合索引进行排序或范围查询，方向很重要。

然而，我看不出为什么指数的方向对复合指数有什么影响。有人能提供进一步的解释（或示例）吗？

Answer 1

理解两个关键点。

1. 虽然一个索引比没有索引好，但正确的索引比任何一个都好

索引不是免费的。它们占用内存，并在执行插入、更新和删除时施加性能惩罚。通常，性能损失可以忽略不计（尤其是与读取性能的提高相比），但这并不意味着我们不能聪明地创建索引。

确定哪些字段组应该被索引在一起是关于理解你正在运行的查询。用于创建索引的字段的顺序至关重要。好消息是，如果你弄错了顺序，索引将根本不会被使用，所以很容易通过解释来发现。

您的查询可能需要排序。但是排序可能是一项昂贵的操作，因此将正在排序的字段与正在查询的字段一样对待很重要。因此，如果有索引，速度会更快。不过有一个重要的区别，排序的字段必须是索引中的最后一个字段。此规则的唯一例外是，如果字段也是查询的一部分，则“必须是最后一个”规则不适用。

可以对索引的所有键或子集指定排序；但是，排序键必须按其在索引中出现的顺序列出。例如，索引键模式{a:1，b:1}可以支持{a:1，b:1}上的排序，但不支持{b:1，a:1}上的排序。

排序必须为其所有键指定与索引键模式相同的排序方向（即升序/降序），或为其所有键指定与索引键模式相反的排序方向。例如，索引键模式{a:1，b:1}可以支持对{a:1，b:1}和{a:-1，b:-1}进行排序，但对{a:-1，b:1}不支持排序。

假设有这些索引：

{ a: 1 }
{ a: 1, b: 1 }
{ a: 1, b: 1, c: 1 }

Example                                                    Index Used
db.data.find().sort( { a: 1 } )                            { a: 1 }
db.data.find().sort( { a: -1 } )                           { a: 1 }
db.data.find().sort( { a: 1, b: 1 } )                      { a: 1, b: 1 }
db.data.find().sort( { a: -1, b: -1 } )                    { a: 1, b: 1 }
db.data.find().sort( { a: 1, b: 1, c: 1 } )                { a: 1, b: 1, c: 1 }
db.data.find( { a: { $gt: 4 } } ).sort( { a: 1, b: 1 } )   { a: 1, b: 1 }

Answer 2

您正在寻找的一个简单答案是，只有在对两个或多个字段进行排序时，方向才起作用。

如果您在排序{a:1，b:-1}:

索引{a:1，b:1}将比索引{a:1，b:-1}

Answer 3

MongoDB以某种方式连接复合键，并将其用作BTree中的键。

在查找单个项目时，树中节点的顺序无关紧要。

如果您要返回一个节点范围-彼此靠近的元素将位于树的相同分支上。节点在范围内越近，检索它们的速度就越快。

使用单个字段索引-顺序无关紧要。如果它们按升序靠近，它们也将按降序靠近。

当你有一个复合键-顺序开始重要。

例如，如果键是A升序B升序，则索引可能如下所示：

Row   A B
1     1 1
2     2 6
3     2 7 
4     3 4
5     3 5
6     3 6
7     5 1

对于升序B和降序B的查询将需要按顺序跳转索引以返回行，并且速度会较慢。例如，它将返回第1、3、2、6、5、4、7行

与索引顺序相同的范围查询只会按正确的顺序返回行。

在BTree中查找记录需要O（Log（n））时间。按顺序查找一系列记录只需OLog（n）k，其中k是要返回的记录数。

如果记录无序，成本可能高达OLog（n）*k