Question

在具有SSD，2个CPU和2GB RAM的Ubuntu 14服务器上，下面的查询需要80多秒（！）。 Mongo 2.4.10，以及约400k记录的集合：

db.content.find({
   "$or": [
       {
           "cik": {
               "$in": [
                   "0000794367",
                   "0000867773"
               ]
           }
       },
       {
           "companiesDetected.ids": {
               "$in": [
                   "biFrixuF7BCyrng6p",
                   "cbCrZSEzHYnPa2PwA"
               ]
           }
       }
   ]
}).limit(100).sort({"pubDate": -1, "title": 1})

我在cik，companiesDetected.ids，pubDate，title以及{"pubDate": -1, "title": 1}上的复合索引上都有索引。这是explain()：

{
    "cursor": "BtreeCursor pubDate_-1_title_1",
    "indexBounds": {
        "pubDate": [
            [
                {
                    "$maxElement": 1
                },
                {
                    "$minElement": 1
                }
            ]
        ],
        "title": [
            [
                {
                    "$minElement": 1
                },
                {
                    "$maxElement": 1
                }
            ]
        ]
    },
    "indexOnly": false,
    "isMultiKey": false,
    "millis": 87903,
    "n": 44,
    "nChunkSkips": 0,
    "nYields": 455,
    "nscanned": 406421,
    "nscannedAllPlans": 406421,
    "nscannedObjects": 406421,
    "nscannedObjectsAllPlans": 406421,
    "scanAndOrder": false,
    "server": "localhost:27017"
}

这里有什么问题？

如果我将查询拆分为构成$or的两个条件，则每个时间都不到100毫秒。

我在dark_shadow's suggestion添加了索引{"cik":1,"companiesDetected.ids":1,"pubDate": -1, "title": 1}，查询上的explain需要111秒。在没有explain的情况下立即重新运行查询需要101秒（连续两次这样做）。没有排序，需要33毫秒（！）。

Answer 1

原来，涉及$or，$in，limit和sort的查询受到MongoDB 2.4.x bug/under-optimization的影响，特别是this issue已被修复2.6.2。

升级到2.6.3解决了问题，现在上面的查询数量级更快（通常在100毫秒以下）。

（如果你想知道我为什么不首先使用2.6.x，那是因为Meteor doesn't yet support Mongo 2.6）。

$或，$ in，sort和limit - 比分割$或的单独查询慢得多

1 个答案: