作者：吳守陽
線上某個頁面的響應(yīng)速度異常緩慢，達(dá)到了16秒，嚴(yán)重影響了業(yè)務(wù)的正常運(yùn)行。經(jīng)過與研發(fā)的溝通得知，該頁面調(diào)用的數(shù)據(jù)集合只會保留7天的數(shù)據(jù)，集合有6000萬條記錄。
作者 | 吳守陽
審校 | 重樓
背景
線上某個頁面的響應(yīng)速度異常緩慢，達(dá)到了16秒，嚴(yán)重影響了業(yè)務(wù)的正常運(yùn)行。經(jīng)過與研發(fā)的溝通得知，該頁面調(diào)用的數(shù)據(jù)集合只會保留7天的數(shù)據(jù)，集合有6000萬條記錄。針對過期數(shù)據(jù)的處理，使用了根據(jù) create_time 字段創(chuàng)建的過期索引，以自動使數(shù)據(jù)失效。此外，數(shù)據(jù)集合還通過 company_id 字段進(jìn)行了哈希分片。
問題排查
慢語句分析
在后臺拿到了慢查詢語句，如下：
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：過期時間的索引
就這點(diǎn)數(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 需要在兩個索引之間進(jìn)行查找和合并，而不是簡單地使用單個索引來解決查詢。
- 額外的查找和合并成本：在涉及多個條件的查詢中，MongoDB 會嘗試使用覆蓋索引（Covered Index）來盡可能地減少在磁盤上的文檔檢索。然而，在這種情況下，create_time_1 索引不能單獨(dú)滿足查詢條件，因此 MongoDB 還需要查找和合并從 company_id_1 索引中過濾出來的文檔。這種額外的查找和合并過程會增加查詢的成本，并且降低性能。
因此，針對給定的查詢語句，MongoDB 不會使用 create_time_1 索引來優(yōu)化查詢，而是會選擇其他更適合的索引，如 company_id_hashed 和 company_id_1。
問題原因
造成執(zhí)行耗時過長的主要原因是索引失效的問題，在涉及多個條件的查詢中，MongoDB 會嘗試使用覆蓋索引（Covered Index）來盡可能地減少在磁盤上的文檔檢索。然而，在這種情況下，create_time_1 索引不能單獨(dú)滿足查詢條件，因此 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: 分片的詳細(xì)信息，包括分片名稱、連接字符串、服務(wù)器信息等。2、winningPlan: 勝出的執(zhí)行計劃。
- stage: 執(zhí)行階段，這里是SINGLE_SHARD，表示單分片操作。
- shardName: 執(zhí)行操作的分片名稱。
- plannerVersion: 計劃版本。
- namespace: 查詢的命名空間。
- indexFilterSet: 是否設(shè)置了索引過濾器。
- parsedQuery: 解析后的查詢條件。
- winningPlan: 勝出的執(zhí)行計劃的詳細(xì)信息，這里是SHARDING_FILTER。3、rejectedPlans: 被拒絕的執(zhí)行計劃列表，即非勝出的備選計劃。
每個被拒絕的執(zhí)行計劃包含了其詳細(xì)信息，包括執(zhí)行階段、過濾器、索引掃描等。
4、executionStats: 查詢的執(zhí)行統(tǒng)計信息。 - nReturned: 返回的文檔數(shù)量。
- executionTimeMillis: 查詢執(zhí)行時間（毫秒）。
- totalKeysExamined: 總共檢查的鍵數(shù)量。
- totalDocsExamined: 總共檢查的文檔數(shù)量。
- executionStages: 執(zhí)行階段的詳細(xì)統(tǒng)計信息。
作者介紹
吳守陽，51CTO社區(qū)編輯，擁有8年DBA工作經(jīng)驗(yàn)，熟練管理MySQL、Redis、MongoDB等開源數(shù)據(jù)庫。精通性能優(yōu)化、備份恢復(fù)和高可用性架構(gòu)設(shè)計。善于故障排除和自動化運(yùn)維，保障系統(tǒng)穩(wěn)定可靠。具備良好的團(tuán)隊(duì)合作和溝通能力，致力于為企業(yè)提供高效可靠的數(shù)據(jù)庫解決方案。
責(zé)任編輯：華軒
來源：
51CTO
