3

長いクエリで実行されている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"]}}

それほど多くの結果をスキャンしないように、このインデックスを作成するために私がしなければならない何か違うことはありますか？

よろしくお願いします。

4

1 に答える 1

4

nscannedカウントは、modTimeが指定された時間よりも大きいドキュメントの総数です。

カラーフィールドに十分な変動性がある場合は、インデックスを逆にして、カラーが最初のフィールドになり、modTimeが2番目のフィールドになるようにすることでメリットが得られる場合があります。

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

これにより、指定された時間よりも長いmodTimeを持つ適切な色のドキュメントの数のみがスキャンされます。コレクションの色が緑、青、黄色のみの場合、メリットはありません。少なくともいくつかの追加の色がある場合は、いくつかの利点が得られるはずです。

警告：modTimeのみを使用するクエリがある場合、それらは新しいインデックスを使用できません。

他の考えられる解決策は、$ lt（または$ lte）式でmodTime範囲を閉じることです。それがクエリで可能かどうか、または評価できるドキュメントの数に違いが生じるかどうかを判断する必要があります。

于 2013-02-19T02:17:59.367 に答える