Mongodb：$ HINT對性能的影響

Question

我有一個查詢，它使用復合索引對“ _id”進行排序。 復合索引在索引的末尾具有“ _id”，並且可以正常工作，直到我向查詢中添加$gt子句為止。

即初始查詢

db.colletion.find({"field1": "blabla", "field2":"blabla"}).sort({_id:1}

后續查詢

db.colletion.find({"field1": "blabla", "field2":"blabla", _id:{$gt:ObjetId('...')}}).sort({_id:1}

我注意到的是有些時候沒有使用我的復合索引。 相反，Mongo使用默認

"BtreeCursor _id_"

為避免這種情況，我向光標添加了一個提示。 我想知道是否會對性能產生影響？ 因為該集合已經具有索引，但是Mongo決定使用其他索引來服務我的查詢。

我注意到的一件事是，當我使用提示時

"cursor" : "QueryOptimizerCursor", "n" : 1, "nscannedObjects" : 2, "nscanned" : 2, "nscannedObjectsAllPlans" : 2, "nscannedAllPlans" : 2, "scanAndOrder" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 0, "server" : "aaa-VirtualBox:27017", "filterSet" : false

花費的時間更快>毫秒

比它在沒有提示的情況下提供相同查詢時

"cursor" : "BtreeCursor _id_", "isMultiKey" : false, "n" : 1, "nscannedObjects" : 1, "nscanned" : 1, "nscannedObjectsAllPlans" : 3, "nscannedAllPlans" : 3, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 3,

使用HINT時，我是否有權衡取舍？ 在大型收藏中，這種表現會不會一樣？

Answer 1

您能指定您創建的復合索引嗎？ 我沒有很多名聲，所以我不能在評論中問這個。 但是我確實有可能回答您的問題。 Mongo使用稱為“ Equal-Sort-Range”的屬性，其行為方式不同。 考慮下面的情況-您的文檔很少，其字段為{name：字符串，pin：六位數，SSN：九位數}，並且有兩個索引-{name：1，pin：1，ssn：1}和第二索引現在是{name：1，ssn：1，pin：1}，請考慮以下查詢：

1. db.test.find({name: "XYZ", pin: 123456"}).sort({ssn: 1})該查詢將使用第一個索引，因為我們有連續的復合索引。name，pin，ssn位於延續。
2. db.test.find({name: "XYZ", pin: {$gt :123456"}}).sort({ssn: 1})您將期望在該查詢中使用第一個索引，但令人驚訝的是秒索引該查詢將使用此查詢，因為它在引腳上具有范圍操作。

Equality-sort-range屬性表示查詢計划者將更好地使用服務於字段的索引-“ equality-sort-range”。 第二個查詢在引腳上具有范圍，因此將使用第二個索引，而第一個查詢在所有字段上均相等，因此將使用第一個索引。