基于字段选择性的复合索引顺序答案

【问题标题】：Compound index order based on field selectivity基于字段选择性的复合索引顺序
【发布时间】：2012-10-15 11:30:11
【问题描述】：

我有两个字段a和b，其中b的选择性明显高于a。 p>

现在，如果我只查询 a 和 b （从不单独查询任何一个字段），以下两个索引中哪个更好以及为什么：

Explain 似乎返回几乎相同的结果，但我在某处读到您应该首先放置更高选择性的字段。我不知道为什么这会有意义。

【问题讨论】：

我大胆猜测第二个索引更好，但您需要对其进行测试。对两个查询运行解释。
@SergioTulentsev 更新了问题...解释似乎对两者都是一样的。
你知道他们怎么说，“如果你看不到差异，那就没有”。 :)
@SergioTulentsev 这可能是正确的答案，想看看我是否遗漏了什么。
有一件事，它可能取决于您查询的方式和查询的顺序，尤其是排序。为了有效地使用索引，排序应该是索引中的最后一个字段。但是我也不确定您所读到的是否属实，至少我从未听说过此案。我听说过并看到复合索引的第一个字段必须匹配查询的第一个字段，但仅此而已。

【解决方案1】：

经过大量工作以改进对 150 000 000 条记录数据库的查询后，我发现了以下内容：

不一定是选择性更高的字段，但实际上匹配“更快”的字段，移动到第一个位置可以显着提高性能

我有一个由以下字段组成的索引：

邮编、地址、城市、名字、姓氏

地址由数组匹配，而不是 string = string，因此执行时间最长，匹配速度最慢。我创建的第一个索引是：address_zip_city_last_name_first_name，将 1000 条记录与整个数据库匹配的执行时间将持续数小时。

地址字段实际上可能对这些具有最高的选择性，但由于它不是通过简单的字符串相等来匹配，因此它花费的时间最多。它实际上是这样的

{ address: {$all : ["1233", "main", "avenue] }}

通过将此索引更改为在开头具有“更快”的字段，例如：zip_city_first_name_last_name_address，性能会好得多。相同的 1000 条记录只需一秒钟即可匹配，而不是持续数小时。

希望这对某人有所帮助

干杯

【讨论】：

【解决方案2】：

经过进一步分析，从性能的角度来看，这两个索引实际上几乎相同。

真的，如果您处于类似情况，真正的考虑应该是将来您是否更有可能单独查询 a 或 b，并且将该字段放在索引中的第一位。

【讨论】：

【解决方案3】：

我相信优化器会选择最适合使用的索引，尽管您可以提供提示

例如

db.collection.find({user:u, foo:d}).hint({user:1});

【讨论】：

虽然这是真的，但它是一个适用于几乎任何 Mongo 场景和查询的通用答案。不幸的是，它对这个特定问题不是很有帮助。
公平点-但我真的建议使用hint()，以便您可以比较每个索引的性能？（我没有顺便说一句） - 但从逻辑上讲，首先索引选择性最少的属性是有意义的，然后你有更少的记录来排序或子过滤。最终，尽管您的索引应该反映您要执行的查询。如果回答没有帮助，请道歉。