【问题标题】:MongoDB $in operator and compound indexMongoDB $in 运算符和复合索引
【发布时间】:2012-03-22 09:33:25
【问题描述】:

我有一个在四个字段上按顺序排列复合索引的集合:(A,B,C,D)

当我像这样查询时

find({A: val1, B: val2, C: val3}).sort({D: 1}).limit(N)

在字段 A、B、C 中使用严格等于,它运行得非常快,应该是这样。 explain() 告诉我只扫描了 N 个文档。

如果我将 equals 之一更改为 $in 运算符(数组中有大约 100 个元素),它会扫描更多数量的文档并且运行速度更慢:

find({A: {$in: [val0, val1, ...]}, B: val2, C: val3}).sort({D: 1}).limit(N)

$or 等其他运算符具有相同的效果。

逻辑上,一个包含 100 个元素的 $in 必须与 100 个严格等于的单独查询非常相似。第二个变体在数据库中运行得更快,但需要在客户端通过后排序和限制获取所有元素(无限制)。

将这个带有$in 的查询拆分成几个带有equals 的查询以减少游标扫描的文档数量是否有意义?如果集合中有数百万个文档,什么会更有效率?

【问题讨论】:

    标签: mongodb indexing


    【解决方案1】:

    您是否使用索引 {B:1,C:1,A:1,D:1} 进行了测试?这样可以快速处理准确的 B 和 C 值,可以在 A 字段上使用范围,并且仍然可以通过索引完成按 D 排序。

    【讨论】:

    • 正如文档所述,由于 MongoDB v1.6.0,复合索引中的字段顺序不再重要:mongodb.org/display/DOCS/Indexing+Advice+and+FAQ 但是,我尝试了您的变体,但没有任何改变。
    • @DenisNP:如果你的意思是this one,那你就错了。字段的顺序确实在索引中很重要。它只是说您可以从(索引定义的)末尾省略一些字段而不会严重影响性能。
    • @SergioTulentsev:我的意思是this yellow frame。我错了吗?
    • @DenisNP:那么,explain() 说了什么?
    猜你喜欢
    • 2011-10-15
    • 1970-01-01
    • 2019-11-02
    • 2012-05-21
    • 1970-01-01
    • 2020-05-28
    • 2021-08-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多