2012-04-19 44 views
2

什么是通过在加盖收集反向插入顺序排序最快的方法(“RF”已经稀疏索引)MongoDB的指标与自然排序优化

db.log.find({ rf : 'o-5556457634'}).sort({ '$natural' : -1 }).explain(); 
{ 
"cursor" : "ReverseCappedCursor", 
"nscanned" : 1654468, 
"nscannedObjects" : 1654468, 
"n" : 4, 
"millis" : 2932, 
"nYields" : 5, 
"nChunkSkips" : 0, 
"isMultiKey" : false, 
"indexOnly" : false, 
"indexBounds" : { 

} 
} 

好像“自然”绕过使用索引('rf')字段显着减慢查询。这是预期的预期行为吗?在查找/索引之后不应该计算'自然'排序吗?

没有“自然”排序:

db.log.find({ rf : 'o-5556457634'}).explain(); 
{ 
"cursor" : "BtreeCursor rf_1", 
"nscanned" : 4, 
"nscannedObjects" : 4, 
"n" : 4, 
"millis" : 0, 
"nYields" : 0, 
"nChunkSkips" : 0, 
"isMultiKey" : false, 
"indexOnly" : false, 
"indexBounds" : { 
    "rf" : [ 
     [ 
      "o-5556457634", 
      "o-5556457634" 
     ] 
    ] 
} 

提示确实迫使发动机使用“RF”指数但结果绕过(反向)“自然”排序

db.log.find({ rf : 'o-5556457634'}).sort({ '$natural' : -1 }).hint({rf :1}).explain(); 
{ 
"cursor" : "BtreeCursor rf_1", 
"nscanned" : 4, 
"nscannedObjects" : 4, 
"n" : 4, 
"scanAndOrder" : true, 
"millis" : 0, 
"nYields" : 0, 
"nChunkSkips" : 0, 
"isMultiKey" : false, 
"indexOnly" : false, 
"indexBounds" : { 
    "rf" : [ 
     [ 
      "o-5556457634", 
      "o-5556457634" 
     ] 
    ] 
} 
} 

回答

1

它看起来像查询优化器在添加sort时做错了事情。

您可以尝试将.hint({rf :1})添加到查询中以查看会发生什么吗?

+0

刚刚更新了提示解释的问题。它确实强制引擎使用'rf'索引,但结果绕过(反向)'自然'排序。 – user1345178 2012-04-20 17:49:18

+0

你有没有尝试过把它移到排序之前? – 2012-04-20 18:16:47

+0

是的,具有相同的结果(被忽略的反向自然排序)。理想情况下,我希望避免'提示'使查询尽可能简单/直观,因为'查找'查询将是动态的。尝试了解是否期望“自然”排序将索引用法从窗口中移出。 – user1345178 2012-04-20 18:26:21

0

面对同样的问题,但找到了解决办法。 您可以在查找过滤器中提及的字段上添加“_id”: - 1字段,然后使用sort({“_ id”: - 1})创建索引。 帮助了我。