MongoDB 計(jì)劃緩存的影響

MongoDB 計(jì)劃緩存的影響

MongoDB 2.6 復(fù)制集Primary創(chuàng)建索引后，發(fā)現(xiàn)Secondary的查詢沒有走最新的索引。

臨時(shí)清理掉該集合的計(jì)劃緩存后正常。筆者觀察到出現(xiàn)性能問題時(shí)，語句并沒有走最優(yōu)的執(zhí)行計(jì)劃。

對(duì)于MongoDB 3.0.3及之前的版本，可以通過如下兩種方法得到解決：  
1. 對(duì)于查詢顯式指定hints。    
2. 設(shè)置查詢計(jì)劃緩存索引過濾器來重寫默認(rèn)查詢計(jì)劃。

在3.0.4版本中修復(fù)了。

SERVER-15225，SERVER-20139  
https://jira.mongodb.org/browse/SERVER-15225

    執(zhí)行計(jì)劃cache的刷新問題，對(duì)同一種類查詢，執(zhí)行計(jì)劃有cache就不去驗(yàn)證，同一種類查詢但是條件不同可能的執(zhí)行情況也不同。

    可以通過internalQueryCacheReplanningEnabled參數(shù)的設(shè)置來解決  
    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可以使用這個(gè)參數(shù)，默認(rèn)是關(guān)閉

查詢計(jì)劃

在給定可用索引的情況下，MongoDB查詢優(yōu)化器處理查詢并且選擇出針對(duì)某查詢而言最高效的查詢計(jì)劃。每次查詢執(zhí)行的時(shí)候，查詢系統(tǒng)都會(huì)使用該查詢計(jì)劃。

查詢優(yōu)化器只會(huì)對(duì)那些看起來有多個(gè)可行計(jì)劃的查詢計(jì)劃進(jìn)行緩存。

集合內(nèi)容發(fā)生改變的時(shí)候，查詢優(yōu)化器會(huì)重新評(píng)估查詢計(jì)劃，以保證最優(yōu)的查詢計(jì)劃。您可以通過使用 索引過濾器 來指定優(yōu)化器評(píng)估的索引。

針對(duì)一個(gè)給定查詢，您可以使用 explain() 方法查看查詢計(jì)劃的統(tǒng)計(jì)。

查詢計(jì)劃修訂

伴隨著集合隨著時(shí)間的變化而變化，在下面幾種情形之一，查詢優(yōu)化器都會(huì)刪除查詢計(jì)劃并且對(duì)其進(jìn)行重新評(píng)估：  
    1. 集合接收1,000個(gè)寫操作。    
    2. The reIndex rebuilds the index.    
    3. 您增加或者刪除一個(gè)索引。    
    4. The mongod process restarts.

緩存查詢計(jì)劃接口

2.6新版功能

MongoDB提供了查詢計(jì)劃緩存命令和方法來查看和修改已緩存的查詢計(jì)劃。

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 新版功能.

索引過濾器會(huì)決定優(yōu)化器評(píng)估哪一個(gè)索引作為一個(gè) query shape 。一個(gè)查詢形狀由查詢、排序以及映射說明組成。如果一個(gè)給定的查詢形狀存在一個(gè)索引過濾器，優(yōu)化器將只會(huì)考慮過濾器中指定的這些索引。

當(dāng)查詢形狀中存在一個(gè)索引過濾器時(shí)，MongoDB將會(huì)忽略 hint() 。如果您想了解MongoDB是否對(duì)一個(gè)查詢使用了索引過濾器，您可以檢查一下 explain() 輸出的 explain.filterSet 字段。

索引過濾器只會(huì)影響到優(yōu)化器評(píng)估的索引，優(yōu)化器有可能會(huì)仍然選擇集合掃描作為某給定查詢形狀的優(yōu)勝方案。

索引過濾器只存在于服務(wù)器進(jìn)程中，在關(guān)機(jī)之后并不會(huì)保存。MongoDB也提供了一個(gè)命令手動(dòng)刪除過濾器。

由于索引過濾器重寫了優(yōu)化器以及 hint() 方法預(yù)期的操作，請(qǐng)合理使用索引過濾器。

db.runCommand(  
   {    
      planCacheSetFilter: "orders",    
      query: { item: "ABC" },    
      projection: { quantity: 1, _id: 0 },    
      sort: { order_date: 1 },    
      indexes: [    
         { item: 1, order_date: 1 , quantity: 1 }    
      ]    
   }    
)