理解Mongo Explain中的索引扫描对于多个结果的影响

Question

我正在努力理解如何更好地构建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"]}}

是否有其他方法可以创建此索引，以便不会扫描那么多结果？

提前感谢您的想法和建议。

- Petrogad

Answer 1

nscanned计数是具有大于所提供时间的modTime的文档总数。

如果颜色字段具有良好的变化性，则可以从反转索引中受益，使颜色成为第一个字段，modTime成为第二个字段。

db.<collection>.createIndex( { color: 1, modTime : -1 } ) 

这样做将仅扫描具有大于提供时间的modTime的正确颜色数量的文档。如果集合中只有绿色、蓝色和黄色，则没有任何好处。如果还有其他颜色，您应该会得到一些好处。

警告：如果您的查询仅使用modTime，则无法使用新索引。

另一个潜在的解决方案是使用$lt（或$lte）表达式关闭modTime范围。您需要确定是否对您的查询可行，或者它是否会影响要评估的可能文档数量。

- Rob Moore