線上MongoDB查詢慢，如何通過索引優(yōu)化直降響應(yīng)時間？

作者：吳守陽 2024-04-29 08:00:00

線上某個頁面的響應(yīng)速度異常緩慢，達到了16秒，嚴重影響了業(yè)務(wù)的正常運行。經(jīng)過與研發(fā)的溝通得知，該頁面調(diào)用的數(shù)據(jù)集合只會保留7天的數(shù)據(jù)，集合有6000萬條記錄。

作者 | 吳守陽

審校 | 重樓

背景

線上某個頁面的響應(yīng)速度異常緩慢，達到了16秒，嚴重影響了業(yè)務(wù)的正常運行。經(jīng)過與研發(fā)的溝通得知，該頁面調(diào)用的數(shù)據(jù)集合只會保留7天的數(shù)據(jù)，集合有6000萬條記錄。針對過期數(shù)據(jù)的處理，使用了根據(jù) create_time 字段創(chuàng)建的過期索引，以自動使數(shù)據(jù)失效。此外，數(shù)據(jù)集合還通過 company_id 字段進行了哈希分片。

問題排查

慢語句分析

在后臺拿到了慢查詢語句，如下：

db.visitor.find({
 "company_id": 13272,
 "create_time": {
 "$gte": ISODate("2024-04-11T00:00:00.000+0800"),
 "$lte": ISODate("2024-04-11T23:59:59.000+0800")
 }
});

db.visitor.find({
 "company_id": 13272,
 "create_time": {
 "$gte": ISODate("2024-04-12T00:00:00.000+0800"),
 "$lte": ISODate("2024-04-18T23:59:59.000+0800")
 }
});

很簡單的一個查詢，語句上沒有再優(yōu)化的必要了。如果索引都在不應(yīng)該出現(xiàn)這種十多秒的耗時，接下來開始分析索引。

索引分析

索引如下：

db.getCollection("visitor").createIndex({
 "company_id": "hashed"
}, {
 name: "company_id_hashed"
});

db.getCollection("visitor").createIndex({
 "company_id": NumberInt("1")
}, {
 name: "company_id_1"
});

db.getCollection("visitor").createIndex({
 "create_time": NumberInt("1")
}, {
 name: "create_time_1",
 expireAfterSeconds: NumberInt("604800")
});

其中：

company_id_hashed：創(chuàng)建集合分片使用的hash索引
company_id_1：普通查詢的索引
create_time_1：過期時間的索引
就這點數(shù)據(jù)量，按理說會用到索引的，不應(yīng)該執(zhí)行耗時16s，接下來執(zhí)行計劃分析。

Explain執(zhí)行計劃

winningPlan

"stage": "SHARDING_FILTER",
 "inputStage": {
 "stage": "FETCH",
 "filter": {
 "$and": [
 {
 "company_id": {
 "$eq": 13272
 }
 },
 {
 "create_time": {
 "$lte": ISODate("2024-04-17T15:59:59.000Z")
 }
 },
 {
 "create_time": {
 "$gte": ISODate("2024-04-10T16:00:00.000Z")
 }
 }
 ]
 },
 "inputStage": {
 "stage": "IXSCAN",
 "keyPattern": {
 "company_id": "hashed"
 },
 "indexName": "company_id_hashed",
 "isMultiKey": false,
 "isUnique": false,
 "isSparse": false,
 "isPartial": false,
 "indexVersion": NumberInt("2"),
 "direction": "forward",
 "indexBounds": {
 "company_id": [
 "[7977521071453068053, 7977521071453068053]"

這部分顯示只用到了company_id_hashed索引，沒有用到create_time_1索引。

rejectedPlans

"stage": "SHARDING_FILTER",
 "inputStage": {
 "stage": "FETCH",
 "filter": {
 "company_id": {
 "$eq": 13272
 }
 },
 "inputStage": {
 "stage": "IXSCAN",
 "keyPattern": {
 "create_time": 1
 },
 "indexName": "create_time_1",
 "isMultiKey": false,
 "multiKeyPaths": {
 "create_time": [ ]
 },
 "isUnique": false,
 "isSparse": false,
 "isPartial": false,
 "indexVersion": NumberInt("2"),
 "direction": "forward",
 "indexBounds": {
 "create_time": [
 "[new Date(1712764800000), new Date(1713369599000)]"
 ]
 }
 }
 }
 },
 {
 "stage": "SHARDING_FILTER",
 "inputStage": {
 "stage": "FETCH",
 "filter": {
 "$and": [
 {
 "create_time": {
 "$lte": ISODate("2024-04-17T15:59:59.000Z")
 }
 },
 {
 "create_time": {
 "$gte": ISODate("2024-04-10T16:00:00.000Z")
 }
 }
 ]
 },
 "inputStage": {
 "stage": "IXSCAN",
 "keyPattern": {
 "company_id": 1
 },
 "indexName": "company_id_1",
 "isMultiKey": false,
 "multiKeyPaths": {
 "company_id": [ ]
 },

這部分顯示的是被拒絕的執(zhí)行計劃列表，不會用到company_id_1、create_time_1索引。

executionStats

"nReturned": NumberInt("229707"),
 "executionTimeMillis": NumberInt("15668"),
 "totalKeysExamined": NumberInt("238012"),
 "totalDocsExamined": NumberInt("238012"),
 "executionStages": {
 "stage": "SINGLE_SHARD",
 "nReturned": NumberInt("229707"),
 "executionTimeMillis": NumberInt("15668"),
 "totalKeysExamined": NumberInt("238012"),
 "totalDocsExamined": NumberInt("238012"),
 "totalChildMillis": NumberLong("15667"),
 "shards": [
 {
 "shardName": "d-m5eee03fdeaeaee4",
 "executionSuccess": true,
 "executionStages": {
 "stage": "SHARDING_FILTER",
 "nReturned": NumberInt("229707"),
 "executionTimeMillisEstimate": NumberInt("14996"),
 "works": NumberInt("238013"),
 "advanced": NumberInt("229707"),
 "needTime": NumberInt("8305"),
 "needYield": NumberInt("0"),
 "saveState": NumberInt("1980"),
 "restoreState": NumberInt("1980"),
 "isEOF": NumberInt("1"),
 "chunkSkips": NumberInt("0"),
 "inputStage": {
 "stage": "FETCH",
 "filter": {
 "$and": [
 {
 "company_id": {
 "$eq": 13272
 }
 },
 {
 "create_time": {
 "$lte": ISODate("2024-04-17T15:59:59.000Z")
 }
 },
 {
 "create_time": {
 "$gte": ISODate("2024-04-10T16:00:00.000Z")
 }
 }
 ]
 },
 "nReturned": NumberInt("229707"),
 "executionTimeMillisEstimate": NumberInt("14595"),
 "works": NumberInt("238013"),
 "advanced": NumberInt("229707"),
 "needTime": NumberInt("8305"),
 "needYield": NumberInt("0"),
 "saveState": NumberInt("1980"),
 "restoreState": NumberInt("1980"),
 "isEOF": NumberInt("1"),
 "docsExamined": NumberInt("238012"),
 "alreadyHasObj": NumberInt("0"),
 "inputStage": {
 "stage": "IXSCAN",
 "nReturned": NumberInt("238012"),
 "executionTimeMillisEstimate": NumberInt("251"),
 "works": NumberInt("238013"),
 "advanced": NumberInt("238012"),
 "needTime": NumberInt("0"),
 "needYield": NumberInt("0"),
 "saveState": NumberInt("1980"),
 "restoreState": NumberInt("1980"),
 "isEOF": NumberInt("1"),
 "keyPattern": {
 "company_id": "hashed"
 },
 "indexName": "company_id_hashed",
 "isMultiKey": false,
 "isUnique": false,
 "isSparse": false,
 "isPartial": false,
 "indexVersion": NumberInt("2"),
 "direction": "forward",
 "indexBounds": {
 "company_id": [
 "[7977521071453068053, 7977521071453068053]"
 ]
 },
 "keysExamined": NumberInt("238012"),
 "seeks": NumberInt("1"),
 "dupsTested": NumberInt("0"),
 "dupsDropped": NumberInt("0")

這部分顯示的是查詢的執(zhí)行統(tǒng)計信息。

索引分析

通過explain的執(zhí)行計劃，可以看出索引的使用上存在問題。按理說company_id、create_time都已創(chuàng)建索引，為什么沒有使用上？是什么原因?qū)е滤В瑳]有用上create_time索引？

下面列舉了失效的情況：

索引選擇性不高：由于查詢條件是一個范圍查詢，create_time 字段可能有許多不同的值滿足條件。因此，單鍵索引 create_time_1 的選擇性（即索引中不同值的比例）可能不高，這使得使用該索引無法有效地減少需要檢索的文檔數(shù)量。
查詢需要跨越多個索引鍵值：查詢涉及到了兩個字段 company_id 和 create_time。雖然索引 create_time_1 可以幫助過濾 create_time 符合條件的文檔，但在執(zhí)行查詢時，還需要考慮 company_id 的匹配條件。因此，MongoDB 需要在兩個索引之間進行查找和合并，而不是簡單地使用單個索引來解決查詢。
額外的查找和合并成本：在涉及多個條件的查詢中，MongoDB 會嘗試使用覆蓋索引（Covered Index）來盡可能地減少在磁盤上的文檔檢索。然而，在這種情況下，create_time_1 索引不能單獨滿足查詢條件，因此 MongoDB 還需要查找和合并從 company_id_1 索引中過濾出來的文檔。這種額外的查找和合并過程會增加查詢的成本，并且降低性能。
因此，針對給定的查詢語句，MongoDB 不會使用 create_time_1 索引來優(yōu)化查詢，而是會選擇其他更適合的索引，如 company_id_hashed 和 company_id_1。

問題原因

造成執(zhí)行耗時過長的主要原因是索引失效的問題，在涉及多個條件的查詢中，MongoDB 會嘗試使用覆蓋索引（Covered Index）來盡可能地減少在磁盤上的文檔檢索。然而，在這種情況下，create_time_1 索引不能單獨滿足查詢條件，因此 MongoDB 還需要查找和合并從 company_id_1 索引中過濾出來的文檔。這種額外的查找和合并過程會增加查詢的成本，并且降低性能。

優(yōu)化方案

創(chuàng)建新的復(fù)合索引company_id_create_time，讓其走company_id_hashed到company_id_create_time的鏈路。添加新的索引后，相同的語句執(zhí)行時間只需要400ms，能滿足業(yè)務(wù)的需求。

結(jié)論

要多關(guān)注索引在什么情況下會失效？復(fù)合索引的先后順序，不是每個條件字段都建個單個普通索引，查詢語句都會使用上，不要存在這種誤區(qū)，有時候復(fù)合索引才是最完美的組合。

執(zhí)行計劃詳解

1、queryPlanner：包含了MongoDB查詢的執(zhí)行計劃。

mongosPlannerVersion：MongoDB計劃版本。
winningPlan：勝出的執(zhí)行計劃，即MongoDB選擇的最佳執(zhí)行計劃。
shards: 分片的詳細信息，包括分片名稱、連接字符串、服務(wù)器信息等。2、winningPlan: 勝出的執(zhí)行計劃。
stage: 執(zhí)行階段，這里是SINGLE_SHARD，表示單分片操作。
shardName: 執(zhí)行操作的分片名稱。
plannerVersion: 計劃版本。
namespace: 查詢的命名空間。
indexFilterSet: 是否設(shè)置了索引過濾器。
parsedQuery: 解析后的查詢條件。
winningPlan: 勝出的執(zhí)行計劃的詳細信息，這里是SHARDING_FILTER。3、rejectedPlans: 被拒絕的執(zhí)行計劃列表，即非勝出的備選計劃。
每個被拒絕的執(zhí)行計劃包含了其詳細信息，包括執(zhí)行階段、過濾器、索引掃描等。
4、executionStats: 查詢的執(zhí)行統(tǒng)計信息。
nReturned: 返回的文檔數(shù)量。
executionTimeMillis: 查詢執(zhí)行時間（毫秒）。
totalKeysExamined: 總共檢查的鍵數(shù)量。
totalDocsExamined: 總共檢查的文檔數(shù)量。
executionStages: 執(zhí)行階段的詳細統(tǒng)計信息。

作者介紹

吳守陽，51CTO社區(qū)編輯，擁有8年DBA工作經(jīng)驗，熟練管理MySQL、Redis、MongoDB等開源數(shù)據(jù)庫。精通性能優(yōu)化、備份恢復(fù)和高可用性架構(gòu)設(shè)計。善于故障排除和自動化運維，保障系統(tǒng)穩(wěn)定可靠。具備良好的團隊合作和溝通能力，致力于為企業(yè)提供高效可靠的數(shù)據(jù)庫解決方案。

責任編輯：華軒來源： 51CTO

MongoDB 索引