Warning: file_get_contents(/data/phpspider/zhask/data//catemap/6/mongodb/11.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
为什么MongoDB在这里使用Scanander?_Mongodb_Mongodb Query - Fatal编程技术网

为什么MongoDB在这里使用Scanander?

为什么MongoDB在这里使用Scanander?,mongodb,mongodb-query,Mongodb,Mongodb Query,我正在MongoDB中保存游戏文档。除此之外,文档还包含玩家姓名(name)、游戏结束时间(endMS)和游戏类型(type)。类型可以有五个不同值中的一个 我需要搜索按游戏结束时间排序的玩家的所有已完成游戏,以及按游戏结束时间排序的具有特定游戏类型的玩家的所有已完成游戏 这两个查询的示例如下 db.games.find({name:“Stefan”,endMS:{$gt:0}}).sort({endMS:-1}) 及 find({name:“Stefan”,type:“bli”,endMS:{

我正在MongoDB中保存游戏文档。除此之外,文档还包含玩家姓名(name)、游戏结束时间(endMS)和游戏类型(type)。类型可以有五个不同值中的一个

我需要搜索按游戏结束时间排序的玩家的所有已完成游戏,以及按游戏结束时间排序的具有特定游戏类型的玩家的所有已完成游戏

这两个查询的示例如下

db.games.find({name:“Stefan”,endMS:{$gt:0}}).sort({endMS:-1})

find({name:“Stefan”,type:“bli”,endMS:{$gt:0}})。sort({endMS:-1})

您可以使用索引

db.games.ensureIndex({name:1,endMS:-1})

ensureIndex({name:1,type:1,endMS:-1})

快速访问

现在,我尝试只使用一个索引:

ensureIndex({name:1,endMS:-1,type:1})

第一个查询或课程仍然运行良好。第二个查询的想法是,Mongo在扫描索引时可能需要跳过一些条目,但只需要访问查询最终返回的文档,因为“类型”已经可以在索引中进行检查。这应该足够快,满足我的需要

然而,使用explain()MongoDB告诉我,像这样查询数据库时需要“scanander”

find({name:“Stefan”,type:“bli”,endMS:{$gt:0}})。sort({endMS:-1})。explain()

nscannedObject和nscanned与上面描述的一样,但我想知道为什么Mongo说Scanander:是的

根据文件: “scanander是一个布尔值,当查询无法使用索引中文档的顺序返回排序结果时,它是真的:MongoDB必须在从光标接收文档后对文档进行排序。”

据我所知,文档应该在索引中排序,只需要跳过一些不影响顺序的文档

那么为什么MongoDB在这里使用Scanander?

自然秩序: 数据库在磁盘上存储文档的顺序。通常,磁盘上文档的顺序反映插入顺序,除非文档因更新操作增大而在内部移动。在capped集合中,插入顺序和自然顺序是相同的,因为文档不会在内部移动。MongoDB以向前的自然顺序返回没有参数的find()查询的文档。MongoDB返回按参数$natural:-1排序的find()查询的反向自然顺序的文档。见$natural


您对插入顺序==索引顺序的假设是错误的。

这似乎是MongoDB 2.6.0-rc0中的一个错误。MongoDB 2.4.9中的所有工作均按预期进行。

Stefan在此处报告了该问题:扫描和测试器问题在2.6.0-rc0之后得到了解决,但解释输出仍存在一些遗留问题。

这不是我的假设。我假设文档是按endMS排序的,因为endMS是复合索引的第二部分。这是一个bug:)。我总是使用排序,如果我期望一个特定的订单,以确保,并优化其他领域,如果性能不达标。你使用的是哪一个版本的MUGDB?奇怪的是,你有一个真实的“扫描者”和一个虚假的“索引者”。我想说您的查询包含索引…我使用的是MongoDB 2.6.0-rc0。搜索不能以索引方式进行,因为它返回整个文档。它只是“indexOnly”的意思,即它不需要扫描文档以确定它是否与查询匹配。奇怪的是,我已经将{u id:0,name:1}作为投影参数添加到查询中,这也不会使查询成为indexOnly。它可能与“type”实际上是“tc.type”有关,因此它取自一个嵌入式文档(我只是想在这里更清楚地说明这个问题)。我记得MongoDB的聚合框架中有一个问题,即当索引的一部分来自嵌入文档时,CoveredIndex会出现问题。但是这也会影响Scanander吗?我做了更多的测试,似乎从嵌入文档中获取的索引条目不是问题所在。我会用2.4版本测试它。如果这是一个错误,你应该
{
    "cursor" : "BtreeCursor name_1_endMS_-1_type_1",
    "isMultiKey" : false,
    "n" : 1,
    "nscannedObjects" : 1,
    "nscanned" : 22,
    "nscannedObjectsAllPlans" : 4,
    "nscannedAllPlans" : 25,
    "scanAndOrder" : true,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
        "name" : [
            [
                "Stefan",
                "Stefan"
            ]
        ],
        "endMS" : [
            [
                Infinity,
                0
            ]
        ],
        "type" : [
            [
                "bli",
                "bli"
            ]
        ]
    },
    "server" : "localhost:27017",
    "filterSet" : false
}