這不是關於批量操作,而是關於「更新」語句中查詢的一般行爲。見SERVER-1599。
因此,在更新語句中從未支持鏈接到.find()
的基本Op_Query
所支持的相同格式的操作。 Bulk API也是如此,因爲.find()
方法存在它自己的方法,屬於Bulk API,它與基本收集方法無關,因此缺少方法.hint()
。
因此,使用$query
的特殊形式即使在.update()
的基本形式下也不起作用。但是對於MongoDB 2.6來說,你可以做一些事情來影響查詢所選擇的索引。
這裏的新增功能是"index filters",它允許您爲給定的「查詢形狀」設置一個索引列表。這裏的主要定義是通過planCacheSetFilter命令。這允許你做類似如下(只是在外殼爲簡潔起見):
db.junk.ensureIndex({ "b": 1, "a": 1 })
db.runCommand({
"planCacheSetFilter": "junk",
"query": { "a": 1 },
"indexes": [
{ "b": 1, "a": 1 }
]
})
在「查詢」的說法有不相關的提供的值,但最重要的是「形」。因此,無論要查詢什麼數據,只要「形狀」基本相同,就會考慮過濾器集。即:
db.junk.find({ "a": 1 }).explain(1).filterSet; // returns true
db.junk.find({ "a": 2 }).explain(1).filterSet; // returns true
db.junk.find({ "b": 1 }).explain(1).filterSet; // returns false, different shape
不像$hint
直接形式,這將既.update()
陳述或散裝.find().update()
鏈的一種方式,以提供查詢操作的指數的選擇工作。
雖然這不是一個「永久性」設置,也不能孤立於單一操作或一系列操作。這個「過濾器」將一直保留在計劃緩存中,直到服務器實例重新啓動。您可以使用planCacheClearFilters命令交替清除它。
因此,直到JIRA Issue解決爲止,「過濾器」是唯一可能的方式,就像您要求實現的一樣,而不用考慮其他查詢來縮小額外的過濾參數以優化可能選擇的索引。