【问题标题】:MongoDB index intersectionMongoDB索引交集
【发布时间】:2014-08-21 16:34:07
【问题描述】:

嘿,我想评估索引交集的性能,但我无法获得两个索引之间的交集。 我已经在本手册中将一些虚拟记录插入到我的数据库中。 http://docs.mongodb.org/manual/core/index-intersection/

插入代码:

for(var i=0;i<1000;i++){
    for(var j=0;j<100;j++){
        db.t.insert({item:"abc"+i,qty:j})
    }
}

指数:

[
    {
        "v" : 1,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "db.t"
    },
    {
        "v" : 1,
        "key" : {
            "qty" : 1
        },
        "name" : "qty_1",
        "ns" : "db.t"
    },
    {
        "v" : 1,
        "key" : {
            "item" : 1
        },
        "name" : "item_1",
        "ns" : "db.t"
    }
]

查询:

db.t.find({item:"abc123",qty:{$gt:15}}).explain()

解释结果:

{
    "cursor" : "BtreeCursor item_1",
    "isMultiKey" : false,
    "n" : 84,
    "nscannedObjects" : 100,
    "nscanned" : 100,
    "nscannedObjectsAllPlans" : 201,
    "nscannedAllPlans" : 305,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 2,
    "nChunkSkips" : 0,
    "millis" : 1,
    "indexBounds" : {
        "item" : [
            [
                "abc123",
                "abc123"
            ]
        ]
    },
    "server" : "brews18:27017",
    "filterSet" : false
}

我的问题是为什么 mongo 只使用 item 作为索引而不使用交集。

提前致谢

【问题讨论】:

  • 你能解释一下吗(真)?我怀疑这是因为 MongoDB 实际上感觉到加载 100 个文档然后过滤掉 16 个比加载一个全新的索引然后与之相交要快

标签: mongodb indexing mongodb-query


【解决方案1】:

好吧,即使在这种情况下它不是,它实际上也是如此。要真正了解正在发生的事情,您需要查看“详细”形式的解释,添加 true:

db.t.find({item:"abc123",qty:{$gt:15}}).explain(true)
{
    "cursor" : "BtreeCursor item_1",
    "isMultiKey" : false,
    "n" : 84,
    "nscannedObjects" : 100,
    "nscanned" : 100,
    "nscannedObjectsAllPlans" : 201,
    "nscannedAllPlans" : 304,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 2,
    "nChunkSkips" : 0,
    "millis" : 2,
    "indexBounds" : {
            "item" : [
                    [
                            "abc123",
                            "abc123"
                    ]
            ]
    },
    "allPlans" : [
            {
                    "cursor" : "BtreeCursor item_1",
                    "isMultiKey" : false,
                    "n" : 84,
                    "nscannedObjects" : 100,
                    "nscanned" : 100,
                    "scanAndOrder" : false,
                    "indexOnly" : false,
                    "nChunkSkips" : 0,
                    "indexBounds" : {
                            "item" : [
                                    [
                                            "abc123",
                                            "abc123"
                                    ]
                            ]
                    }
            },
            {
                    "cursor" : "BtreeCursor qty_1",
                    "isMultiKey" : false,
                    "n" : 0,
                    "nscannedObjects" : 101,
                    "nscanned" : 102,
                    "scanAndOrder" : false,
                    "indexOnly" : false,
                    "nChunkSkips" : 0,
                    "indexBounds" : {
                            "qty" : [
                                    [
                                            15,
                                            Infinity
                                    ]
                            ]
                    }
            },
            {
                    "cursor" : "Complex Plan",
                    "n" : 0,
                    "nscannedObjects" : 0,
                    "nscanned" : 102,
                    "nChunkSkips" : 0
            }
    ],

简而言之,但最后一部分是您正在寻找的。如explained in the manual,“复杂计划”的出现意味着正在使用交叉口。

            {
                    "cursor" : "Complex Plan",
                    "n" : 0,
                    "nscannedObjects" : 0,
                    "nscanned" : 102,
                    "nChunkSkips" : 0
            }

这里唯一的情况是,当它被“查看”时,优化器在这种情况下没有选择它作为最“最优”的查询。所以优化器是在说,实际上只使用一个选定索引的计划是以最响应的方式完成的。

因此,虽然考虑了“交叉点”,但它并不是“最合适的”,因此选择了单个索引。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2014-10-05
    • 1970-01-01
    • 1970-01-01
    • 2015-08-18
    • 1970-01-01
    • 2014-03-23
    • 2013-10-11
    相关资源
    最近更新 更多