日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

作者 | 吳守陽

審校 | 重樓

背景

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

問題排查

慢語句分析

在后臺(tái)拿到了慢查詢語句，如下：

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")
 }
});

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

索引分析

索引如下：

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í)間的索引
  就這點(diǎn)數(shù)據(jù)量，按理說會(huì)用到索引的，不應(yīng)該執(zhí)行耗時(shí)16s，接下來執(zhí)行計(jì)劃分析。

ExplAIn執(zhí)行計(jì)劃

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í)行計(jì)劃列表，不會(huì)用到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)計(jì)信息。

索引分析

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

下面列舉了失效的情況：

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

問題原因

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

優(yōu)化方案

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

結(jié)論

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

執(zhí)行計(jì)劃詳解

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

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

作者介紹

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