查看執行計劃
索引優化是一個永遠都繞不過的話題,作爲NoSQL的MongoDB也不例外。Mysql中通過explain命令來查看對應的索引信息,MongoDB亦如此。
1. db.collection.explain().<method(...)>
db.products.explain().remove( { category: "apparel" }, { justOne: true })
2. db.collection.<method(...)>.explain({})
db.products.remove( { category: "apparel" }, { justOne: true }).explain()
如果你是在mongoshell 中第一種和第二種沒什麼區別，如果你是在robot 3T這樣的客戶端工具中使用你必須在後面顯示調用finish()或者next()
db.collection.explain().find({}).finish()
explain有三種模式,分別是:
- queryPlanner(默認) ：queryPlanner模式下並不會去真正進行query語句查詢，而是針對query語句進行執行計劃分析並選出winning plan
- executionStats ：MongoDB運行查詢優化器以選擇獲勝計劃(winning plan)，執行獲勝計劃直至完成，並返回描述獲勝計劃執行情況的統計信息。
- allPlansExecution: queryPlanner和executionStats都返回。相當於 explain("allPlansExecution") = explain({})
queryPlanner(查詢計劃)
日誌表中存儲了用戶的操作日誌,我們經常查詢某一篇文章的操作日誌,數據如下:
{
"_id" : NumberLong(7277744),
"operatorName" : "autotest_cp",
"operateTimeUnix" : NumberLong(1586511800890),
"module" : "ARTICLE",
"opType" : "CREATE",
"level" : "GENERAL",
"recordData" : {
"articleId" : "6153324",
"categories" : "100006",
"title" : "testCase-2 this article is created for cp edior to search",
"status" : "DRAFT"
},
"responseCode" : 10002
}
集合中大概有700萬數據,對於這樣的查詢語句
db.getCollection('operateLog').find({"module": "ARTICLE", "recordData.articleId": "6153324"}).sort({_id:-1})
首先看下queryPlanner返回的內容：
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "smcp.operateLog",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"module" : {
"$eq" : "ARTICLE"
}
},
{
"recordData.articleId" : {
"$eq" : "6153324"
}
}
]
},
"winningPlan" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"module" : {
"$eq" : "ARTICLE"
}
},
{
"recordData.articleId" : {
"$eq" : "6153324"
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"_id" : 1
},
"indexName" : "_id_",
"isMultiKey" : false,
"multiKeyPaths" : {
"_id" : []
},
"isUnique" : true,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "backward",
"indexBounds" : {
"_id" : [
"[MaxKey, MinKey]"
]
}
}
},
"rejectedPlans" : [
{
"stage" : "SORT",
"sortPattern" : {
"_id" : -1.0
},
"inputStage" : {
"stage" : "SORT_KEY_GENERATOR",
"inputStage" : {
"stage" : "FETCH",
"filter" : {
"recordData.articleId" : {
"$eq" : "6153324"
}
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"module" : 1.0,
"opType" : 1.0
},
"indexName" : "module_1_opType_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"module" : [],
"opType" : []
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"module" : [
"[\"ARTICLE\", \"ARTICLE\"]"
],
"opType" : [
"[MinKey, MaxKey]"
]
}
}
}
}
}
]
}
字段含義
一些重要字段的含義
- queryPlanner.namespace查詢的哪個表
- queryPlanner.winningPlan查詢優化器針對該query所返回的最優執行計劃的詳細內容。
- queryPlanner.winningPlan.stage最優計劃執行的階段,每個階段都包含特定於該階段的信息。例如，IXSCAN階段將包括索引範圍以及特定於索引掃描的其他數據。如果一個階段具有一個子階段或多個子階段，那麼該階段將具有inputStage或inputStages。
- queryPlanner.winningPlan.inputStage描述子階段的文檔，該子階段向其父級提供文檔或索引鍵。如果父階段只有一個孩子，則該字段存在。
- queryPlanner.winningPlan.inputStage.indexNamewinning plan所選用的index,這裏是根據_id來進行排序的，所以使用了_id的索引
- queryPlanner.winningPlan.inputStage.isMultiKey是否是Multikey，此處返回是false，如果索引建立在array上，此處將是true
- queryPlanner.winningPlan.inputStage.isUnique使用的索引是否是唯一索引，這裏的_id是唯一索引
- queryPlanner.winningPlan.inputStage.isSparse是否是稀疏索引
- queryPlanner.winningPlan.inputStage.isPartial是否是部分索引
- queryPlanner.winningPlan.inputStage.direction 此query的查詢順序，默認是forward，由於使用了sort({_id:-1})顯示backward
- queryPlanner.winningPlan.inputStage.indexBoundswinningplan所掃描的索引範圍,由於這裏使用的是sort({_id:-1}),對_id倒序排序,所以範圍是[MaxKey,MinKey]。如果是正序,則是[MinKey,MaxKey]
- queryPlanner.rejectedPlans拒絕的計劃詳細內容,各字段含義同winningPlan
executionStats(執行結果)
再來看下executionStats的返回結果
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 1,
"executionTimeMillis" : 24387,
"totalKeysExamined" : 6998084,
"totalDocsExamined" : 6998084,
"executionStages" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"module" : {
"$eq" : "ARTICLE"
}
},
{
"recordData.articleId" : {
"$eq" : "6153324"
}
}
]
},
"nReturned" : 1,
"executionTimeMillisEstimate" : 1684,
"works" : 6998085,
"advanced" : 1,
"needTime" : 6998083,
"needYield" : 0,
"saveState" : 71074,
"restoreState" : 71074,
"isEOF" : 1,
"invalidates" : 0,
"docsExamined" : 6998084,
"alreadyHasObj" : 0,
"inputStage" : {
"stage" : "IXSCAN",
"nReturned" : 6998084,
"executionTimeMillisEstimate" : 290,
"works" : 6998085,
"advanced" : 6998084,
"needTime" : 0,
"needYield" : 0,
"saveState" : 71074,
"restoreState" : 71074,
"isEOF" : 1,
"invalidates" : 0,
"keyPattern" : {
"_id" : 1
},
"indexName" : "_id_",
"isMultiKey" : false,
"multiKeyPaths" : {
"_id" : []
},
"isUnique" : true,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "backward",
"indexBounds" : {
"_id" : [
"[MaxKey, MinKey]"
]
},
"keysExamined" : 6998084,
"seeks" : 1,
"dupsTested" : 0,
"dupsDropped" : 0,
"seenInvalidated" : 0
}
},
"allPlansExecution" : [
{...},
{...}
]
}
字段解析
- executionStats.executionSuccess是否執行成功
- executionStats.nReturned查詢的返回條數
- executionStats.executionTimeMillis選擇查詢計劃和執行查詢所需的總時間（以毫秒爲單位）
- executionStats.totalKeysExamined索引掃描次數
- executionStats.totalDocsExamineddocument掃描次數
- executionStats.executionStages以階段樹的形式詳細說明獲勝計劃的完成執行情況；即一個階段可以具有一個inputStage或多個inputStages。如上說明。
- executionStats.executionStages.inputStage.keysExamined掃描了多少次索引
- executionStats.executionStages.inputStage.docsExamined掃描了多少次文檔，一般當stage是 COLLSCAN的時候會有這個值。
- exlexecutionStats.allPlansExecution這裏展示了所有查詢計劃的詳細。(winningPlan + rejectPlans),字段含義和winningPlan中一致，不做贅述
15種stage
從上面可以看出stage是很重要的，一個查詢到底走的是索引還是全表掃描主要看的就是stage的值, 而stage有如下值
- COLLSCAN : 掃描整個集合
- IXSCAN : 索引掃描(index scan)
- FETCH : 根據索引返回的結果去檢索文檔(如上我們的例子)
- SHARD_MERGE : 將各個分片返回數據進行merge
- SORT : 調用了sort方法,當出現這個階段的時候你可以看到memUsage以及memLimit這兩個字段
- SORT_KEY_GENERATOR : 在內存中進行了排序
- LIMIT ： 使用limit限制返回數
- SKIP ： 使用skip進行跳過
- IDHACK ： 針對_id進行查詢
- SHARDING_FILTER ：通過mongos對分片數據進行查詢
- COUNT: 利用db.coll.explain().count()之類進行count運算, 只要調用了count方法，那麼 executionStats.executionStages.stage = COUNT
- COUNT_SCAN : count使用Index進行count時的stage返回
{
country: "ID",
name: "jjj",
status: 0
},
{
country: "ZH",
name: "lisi",
status: 1
}
我們對country字段建立了索引，同時執行下面的語句
db.getCollection('testData').explain(true).count({country: "ID"})
那麼查看執行結果可以看到 executionStats.executionStages.inputStage.stage = COUNT_SCAN, COUNT_SCAN是COUNT的一個子階段。
- COUNTSCAN : count不使用Index進行count時的stage返回。
db.getCollection('testData').explain(true).count({status: 0})
此時 executionStats.executionStages.inputStage.stage = COUNTSCAN , COUNTSCAN是COUNT的一個子階段
- SUBPLAN : 未使用到索引的$or查詢的stage返回
db.getCollection('testData').find({$or : [{name : "lisi"}, {status: 0}]}).explain(true);
此時 executionStats.executionStages.stage = SUBPLAN
- TEXT : 使用全文索引進行查詢時候的stage返回
- PROJECTION : 限定返回字段時候stage的返回
查看executionStats.executionStages.stage以及其下各個inputStage(子階段)的值是什麼,可以判定存在哪些優化點。
一個查詢它掃描的文檔數要儘可能的少,才能更快，明顯我們我們不希望看到COLLSCAN, SORT_KEY_GENERATOR, COUNTSCAN, SUBPLAN 以及不合理的 SKIP 這些stage,當你看到這些stage的時候就要注意了。
查詢優化
當你看winningPlan或者rejectPlan的時候，你就可以知道執行順序是怎樣的，比如我們rejectPlan中，先是通過 "module_1_opType_1"檢索 "module = ARTICLE"的數據，然後FETCH階段再通過 "recordData.articleId=6153324"進行過濾，最後在內存中排序後返回數據。 明顯這樣的計劃被拒絕了，至少它沒有winningPlan執行快。
再來看看executionStats返回的數據
nReturned 爲 1，即符合條件的只有1條
executionTimeMillis 值爲24387,執行時間爲24秒
totalKeysExamined 值爲 6998084,雖然用到了索引，但是幾乎是掃描了所有的key
totalDocsExamined的值爲6998084,也是掃描了所有文檔
從上面的輸出結果可以看出來，雖然我們使用了索引，但是速度依然很慢。很明顯現在的索引，並不適合我們，爲了排除干擾，我們先將module_1_opType_1這個索引刪除。由於我們這裏使用了兩個字段進行查詢，而 recordData.articleId這個字段並不是每個document(集合中還存儲了其他類型的數據)都存在，所以建立索引的時候recordData.articleId需要建立部分索引
db.getCollection('operateLog').createIndex(
{'module': 1, 'recordData.articleId': 1 },
{
"partialFilterExpression": {
"recordData.articleId": {
"$exists": true
}
},
"background": true
}
)
我先吃個蘋果，等它把索引建立好，大家有啥吃啥。在索引建立完成之後，我們來看看 executionStats 的結果
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 1,
"executionTimeMillis" : 3,
"totalKeysExamined" : 1,
"totalDocsExamined" : 1,
"executionStages" : {
"stage" : "SORT",
"sortPattern" : {
"_id" : -1.0
},
"memUsage" : 491,
"memLimit" : 33554432,
"inputStage" : {
"stage" : "SORT_KEY_GENERATOR",
"inputStage" : {
"stage" : "FETCH",
"nReturned" : 1,
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"module" : 1.0,
"recordData.articleId" : 1.0
},
"indexName" : "module_1_recordData.articleId_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"module" : [],
"recordData.articleId" : []
},
"isPartial" : true,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"module" : [
"[\"ARTICLE\", \"ARTICLE\"]"
],
"recordData.articleId" : [
"[\"6153324\", \"6153324\"]"
]
}
}
}
}
}
}
我忽略了一些不重要的字段,可以看到，現在執行時間是3毫秒(executionTimeMillis=3),掃描了1個index(totalKeysExamined=1),掃描了1個document(totalDocsExamined=1)。相比於之前的24387毫秒，我可以說我的執行速度提升了8000倍，我就問還有誰。如果此事讓UC 震驚部小編知道了，肯定又可以起一個震驚的標題了
但是這個執行計劃仍然有問題，有問題，有問題，重要的事情說三遍。 executionStages.stage = sort,證明它在內存中排序了,在數據量大的時候，是很消耗性能的，所以千萬不能忽視它，我們要改進這個點。
我們要在 nReturned = totalDocsExamined的基礎上，讓排序也走索引。所以我們先將之前的索引刪除，然後重新創建索引，這裏我們將_id字段也加入到索引中，三個字段形成組合索引
db.getCollection('operateLog').createIndex(
{'module': 1, 'recordData.articleId': 1, '_id': -1},
{
"partialFilterExpression": {
"recordData.articleId": {
"$exists": true
}
},
"background": true
}
)
同樣的再來看看我們的執行結果:
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 1,
"executionTimeMillis" : 0,
"totalKeysExamined" : 1,
"totalDocsExamined" : 1,
"executionStages" : {
"stage" : "FETCH",
"nReturned" : 1,
"executionTimeMillisEstimate" : 0,
"docsExamined" : 1,
"inputStage" : {
"stage" : "IXSCAN",
"nReturned" : 1,
"keyPattern" : {
"module" : 1.0,
"recordData.articleId" : 1.0,
"_id" : -1.0
},
"indexName" : "module_1_recordData.articleId_1__id_-1",
"multiKeyPaths" : {
"module" : [],
"recordData.articleId" : [],
"_id" : []
},
"isPartial" : true,
"direction" : "forward",
"indexBounds" : {
"module" : [
"[\"ARTICLE\", \"ARTICLE\"]"
],
"recordData.articleId" : [
"[\"6153324\", \"6153324\"]"
],
"_id" : [
"[MaxKey, MinKey]"
]
}
}
}
}
可以看到我們這次的stage是FETCH+IXSCAN,同時 nReturned = totalKeysExamined = totalDocsExamined = 1，並且利用了index排序，而非在內存中排序。從executionTimeMillis=0也可以看出來，性能相比於之前的3毫秒也有所提升，至此這個索引就是我們需要的了。
最開頭的結果和優化的過程告訴我們,使用了索引你的查詢仍然可能很慢,我們要將更多的目光集中到掃描的文檔或者行數中。
索引優化準則
- 根據ESR原則創建索引精確(Equal)匹配的字段放最前面,排序(Sort)條件放中間,範圍(Range)匹配的字段放最後面,同樣適用於ES,ER。
- 每一個查詢都必須要有對應的索引
- 儘量使用覆蓋索引 Covered Indexes(可以避免讀數據文件)需要查詢的條件以及返回值均在索引中
- 使用 projection 來減少返回到客戶端的的文檔的內容
- 儘可能不要計算總數,特別是數據量大和查詢不能命中索引的時候
- 避免使用skip/limit形式的分頁，特別是數據量大的時候
替代方案:使用查詢條件+唯一排序條件
第一頁：db.posts.find({}).sort({_id: 1}).limit(20)
第二頁：db.posts.find({_id: {$gt: <第一頁最後一個_id>}}).sort({_id: 1}).limit(20)
第三頁：db.posts.find({_id: {$gt: <第二頁最後一個_id>}}).sort({_id: 1}).limit(20)