$或$ in排序和限制 - 比獨立查詢拆分$或

Question

的查詢速度慢得多在具有SSD，2個CPU和2GB RAM的Ubuntu 14服務器上，以下查詢需要80多秒（！）。蒙戈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的兩個條件，則每個時間都小於100ms。

我添加了索引{"cik":1,"companiesDetected.ids":1,"pubDate": -1, "title": 1}在dark_shadow's suggestion和查詢的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解決了問題，現在上面的查詢是數量級更快（通常在100ms以下）。

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