0

考虑 Mongo 的Compound Indexing示例：

Example Given the following index:
{ "item": 1, "location": 1, "stock": 1 }
MongoDB can use this index to support queries that include:   

 - the item field, and
 - the item field and the location field, and
 - the item field and the location field and the stock field.

MongoDB cannot use this index to support queries that include:


 - only the location field,
 - only the stock field,
 - only the location and stock fields, and
 - only the item and stock fields.

与简单的排列相比，是否有更好的最小索引数才能支持项目、位置和库存的任何“精确匹配”查询组合？

编辑

为了解决上面缺少的索引，我可以添加Location、Stock、Location-Stock和Item-Stock索引。请注意，最后 2 个是复合索引，用于处理我的问题中列出的所有查询。

但是，在尝试处理 N 个字段的所有排列时是否有一般规则？

4

1 回答 1

0

我可以添加Location、Stock、Location-Stock和Item-Stock索引。请注意，最后 2 个是复合索引，用于处理我的问题中列出的所有查询。

如果有Location-Stock，则不需要单独的Location索引。

您可能想观看MongoDB 的 Jira 以获取关于 index intersection 的更新。索引交集将解决这个问题。新的匹配器已经在 2.5 分支中。

一般来说，（几乎）所有的排列都是不可行的，因为排列的数量是N!，所以 4 个字段有 24 个索引，5 个字段有 120 个索引。

确保您的索引选择性良好。这在很大程度上取决于数据（即关系的分布方式）和应用程序（您需要的查询），这使得讨论变得棘手。

例如，假设一个典型的客户有 5,000 件库存商品，但没有人拥有超过 5 个位置。在这种情况下，location索引可能不会有太大帮助。最坏的情况是查询特定位置的所有项目。数据库必须查看 25k 文档才能返回 5k 结果。

这不是太有效，但用户不太可能想要经常查询整个列表。对于您只想显示第一页的典型应用程序，此查询的有效性将取决于插入顺序和主键的类型：如果文档具有随机键，则数据库将不得不扫描5n文档以返回n结果平均。但是，如果主键是单调的并且数据是逐个位置插入的，那么数据库可能必须扫描并跳过 20k 个元素才能找到第一个结果！

因此，长答案是：索引是一种必须根据您需要的数据和查询进行仔细调整的工具，因此没有普遍适用的最低限度有助于实际目的。

于 2013-09-26T07:17:40.513 回答