【问题标题】:Understanding Mongo Explain Index scanning to many results了解 Mongo Explain Index 扫描到许多结果
【发布时间】:2013-02-13 20:55:26
【问题描述】:

我正在尝试了解如何更好地为我看到的长查询运行的 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"]}}

我应该做一些不同的事情来创建这个索引,这样它就不会扫描这么多结果吗?

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

【问题讨论】:

    标签: mongodb optimization indexing


    【解决方案1】:

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

    如果颜色字段具有良好的可变性,那么您可能会从反转索引中受益,以便颜色是第一个字段,modTime 是第二个字段。

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

    然后,这将仅扫描 modTime 大于提供的时间的正确颜色的文档数量。如果集合中唯一的颜色是绿色、蓝色、黄色,则没有任何好处。如果至少有一些额外的颜色,你应该会得到一些好处。

    警告:如果您有只使用 modTime 的查询,那么他们将无法使用新索引。

    另一个可能的解决方案是使用 $lt(或 $lte)表达式关闭 modTime 范围。您必须确定您的查询是否可以这样做,或者它是否会影响要评估的可能文档的数量。

    【讨论】:

      猜你喜欢
      • 2020-07-01
      • 2021-04-19
      • 2016-08-24
      • 2018-10-11
      • 2016-09-20
      • 2019-09-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多