您好,登錄后才能下訂單哦!
MongoDB 計劃緩存的影響
MongoDB 2.6 復制集Primary創建索引后,發現Secondary的查詢沒有走最新的索引。
臨時清理掉該集合的計劃緩存后正常。筆者觀察到出現性能問題時,語句并沒有走最優的執行計劃。
對于MongoDB 3.0.3及之前的版本,可以通過如下兩種方法得到解決:
1. 對于查詢顯式指定hints。
2. 設置查詢計劃緩存索引過濾器來重寫默認查詢計劃。
在3.0.4版本中修復了。
SERVER-15225,SERVER-20139
https://jira.mongodb.org/browse/SERVER-15225
執行計劃cache的刷新問題,對同一種類查詢,執行計劃有cache就不去驗證,同一種類查詢但是條件不同可能的執行情況也不同。
可以通過internalQueryCacheReplanningEnabled參數的設置來解決
The query optimizer caches plans for each query shape and reuses these plans for a time. In situations where the performance of the cached plan is poor for a particular instance of the query shape, the optimizer may select a the plan with poor performance and fail to evict the cache entry. This behavior may impact deployments where two queries with the same shape have different performance characteristics if they have different selectivity.
This improvement makes the query planner evaluate the cost of the cached query plan, and if the cost of this plan is too high, the query planner switches to a more efficient plan. This more efficient plan is then cached for future use.
This improvement is not enabled by default. To enable by default set the internalQueryCacheReplanningEnabled parameter totrue using the setParameter command on a running system, or at start time using the setParameter commandline option orsetParameter in the configuration file.
For example, to enable using setParameter:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: true})
This improvement can be disabled as follows:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: false})
3.0.4可以使用這個參數,默認是關閉
查詢計劃
在給定可用索引的情況下,MongoDB查詢優化器處理查詢并且選擇出針對某查詢而言最高效的查詢計劃。每次查詢執行的時候,查詢系統都會使用該查詢計劃。
查詢優化器只會對那些看起來有多個可行計劃的查詢計劃進行緩存。
集合內容發生改變的時候,查詢優化器會重新評估查詢計劃,以保證最優的查詢計劃。您可以通過使用 索引過濾器 來指定優化器評估的索引。
針對一個給定查詢,您可以使用 explain() 方法查看查詢計劃的統計。
查詢計劃修訂
伴隨著集合隨著時間的變化而變化,在下面幾種情形之一,查詢優化器都會刪除查詢計劃并且對其進行重新評估:
1. 集合接收1,000個寫操作。
2. The reIndex rebuilds the index.
3. 您增加或者刪除一個索引。
4. The mongod process restarts.
緩存查詢計劃接口
2.6新版功能
MongoDB提供了查詢計劃緩存命令和方法來查看和修改已緩存的查詢計劃。
db.runCommand( { planCacheListFilters: Product } ) db.runCommand( { planCacheListPlans: "Product", query: { Path: /^9-1-6(-\d+)*$/, "Status": { $lt: 4 } } } ) db.runCommand( { planCacheClear: "Product", query: { Path: /^9-1-6(-\d+)*$/, "Status": { $lt: 4 } } } ) db.runCommand( { planCacheClear: "Product" } )
索引過濾器
2.6 新版功能.
索引過濾器會決定優化器評估哪一個索引作為一個 query shape 。一個查詢形狀由查詢、排序以及映射說明組成。如果一個給定的查詢形狀存在一個索引過濾器,優化器將只會考慮過濾器中指定的這些索引。
當查詢形狀中存在一個索引過濾器時,MongoDB將會忽略 hint() 。如果您想了解MongoDB是否對一個查詢使用了索引過濾器,您可以檢查一下 explain() 輸出的 explain.filterSet 字段。
索引過濾器只會影響到優化器評估的索引,優化器有可能會仍然選擇集合掃描作為某給定查詢形狀的優勝方案。
索引過濾器只存在于服務器進程中,在關機之后并不會保存。MongoDB也提供了一個命令手動刪除過濾器。
由于索引過濾器重寫了優化器以及 hint() 方法預期的操作,請合理使用索引過濾器。
db.runCommand( { planCacheSetFilter: "orders", query: { item: "ABC" }, projection: { quantity: 1, _id: 0 }, sort: { order_date: 1 }, indexes: [ { item: 1, order_date: 1 , quantity: 1 } ] } )
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。