我正在尝试了解如何更好地为Mongo查询构建索引,我看到这些查询运行了长查询。
目前我看到的是这样的事情:
"cursor" : "BtreeCursor modTime_-1_color_1 multi",
"isMultiKey" : false,
"n" : 0,
"nscannedObjects" : 0,
"nscanned" : 104936,
"nscannedObjectsAllPlans" : 104935,
"nscannedAllPlans" : 314806,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 70,
"nChunkSkips" : 0,
"millis" : 14237,
"indexBounds" : {
"modTime" : [
[
{
"$maxElement" : 1
},
{
"sec" : 1360267645,
"usec" : 0
}
]
],
"color" : [
[
"Green",
"Green"
],
[
"Blue",
"Blue"
],
[
"Yellow",
"Yellow"
]
]
},
查询类似于:
{"modTime":{"$gte":{"sec":1360267645,"usec":0}},"color":{"$in":["Green","Blue","Yellow"]}}
我是否应该做一些不同的事情来创建这个索引,以便它不扫描这么多结果?
提前感谢您的想法和建议。
答案 0 :(得分:4)
nscanned count是modTime大于提供的时间的文档总数。
如果颜色区域存在良好的可变性,那么您可以从反转索引中获益,以便颜色是第一个字段,modTime是第二个字段。
db.<collection>.createIndex( { color: 1, modTime : -1 } )
然后,这将仅扫描正确颜色的文档数量,其中modTime大于提供的时间。如果系列中唯一的颜色是绿色,蓝色,黄色则没有任何好处。如果至少有一些额外的颜色,你应该得到一些好处。
警告:如果您的查询仅使用modTime,则他们将无法使用新索引。
另一个可能的解决方案是使用$ lt(或$ lte)表达式关闭modTime范围。您必须确定您的查询是否可行,或者是否会对要评估的可能文档数量产生影响。