View a markdown version of this page

查詢執行緩慢 - Amazon DocumentDB
識別 - 找出問題調查 — 收集資訊診斷 — 尋找根本原因解決 — 修正問題

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

查詢執行緩慢

識別 - 找出問題

慢速執行查詢是超過您業務需求預期執行時間的查詢。構成慢查詢的定義會因不同的工作負載而有所不同。您可以透過分析器日誌或績效詳情來識別慢查詢。

  1. 如果尚未啟用，請啟用分析器。Profiler 日誌會寫入日誌群組下的 Amazon CloudWatch：/aws/docdb/<cluster-identifier>/profiler。使用 CloudWatch Logs Insights 來查詢它們。

    取得電子商務產品集合 10 個最慢查詢的 CloudWatch 日誌分析查詢範例：

    
filter ns="ecommerce.products" | sort millis desc | limit 10

  2. 使用績效詳情近乎即時地識別昂貴的查詢。如果尚未啟用績效詳情，請將其啟用。

    1. 開啟 AWS 主控台，導覽至 Amazon Amazon DocumentDB，然後 Performance Insights，然後選取您的叢集執行個體。

    2. 檢閱資料庫載入 (AAS) 時間軸和熱門查詢 （依資料庫載入）。展開查詢摘要以檢視文字子陳述式。

    3. 擷取需要分析的查詢。

    注意

    並非所有績效詳情中的查詢都無效或緩慢查詢。

調查 — 收集資訊

  1. 分析工具提供與其相關聯的查詢執行計畫和關鍵指標，包括毫秒、Nreturned 和 planSummary （索引用量）：

    
{
    "op": "query",
    "ts": 1721374275673,
    "ns": "test.perf",
    "command": {
        "find": "perf",
        "filter": {
            "threadRunCount": 0
        },
        "$db": "test",
        "lsid": {
            "id": {
                "$binary": "oO2wEtpgQIK+y9KGByYnsw==",
                "$type": "4"
            }
        },
        "$readPreference": {
            "mode": "secondaryPreferred"
        }
    },
    "cursorExhausted": true,
    "nreturned": 0,
    "responseLength": 0,
    "protocol": "op_query",
    "millis": 137,
    "planSummary": "IXSCAN",
    "execStats": {
        "stage": "FETCH",
        "nReturned": "0",
        "executionTimeMillisEstimate": "100.346",
        "inputStage": {
            "stage": "IXSCAN",
            "nReturned": "0",
            "executionTimeMillisEstimate": "100.342",
            "indexName": "threadRunCount_1"
        }
    },
    "client": "172.31.6.165:43154",
    "appName": "ProdAppTester14",
    "user": "adminuser"
}

    若要尋找 COLLSCAN 查詢：

    
filter planSummary="COLLSCAN" | sort millis desc | limit 20

  2. 使用績效詳情來即時分析查詢執行趨勢，例如等待、載入和資源影響 （例如每個查詢的 IOPS 或 CPU)。

    由於 Performance Insights 不提供查詢執行計畫，請擷取查詢，並在 Amazon DocumentDB 叢集上的查詢上執行 explain("executionStats")：

    
db.ecommerce.products.find().explain("executionStats")

  3. 或者，將分析器指標與績效詳情資料建立關聯 （例如，將分析器中的高毫秒查詢與績效詳情中的常用查詢進行比對）。

診斷 — 尋找根本原因

在此步驟中，診斷查詢計畫以識別潛在的最佳化。使用下列流程 - 症狀 → 可能原因：

  • 徵狀： planSummary： "COLLSCAN"

    原因：索引遺失或不正確。

  • 徵狀：使用 $group / $sort 緩慢彙總

    原因：彙總管道可能正在處理記憶體中的過多資料。

  • 徵狀：高延遲，而績效詳情會顯示依 IO 分組的資料庫負載等待，但會使用索引 (planSummary： "IXSCAN")。

    原因：I/O 繫結查詢；索引或工作集超過執行個體上可用的緩衝區快取。

  • 徵狀：PI 顯示 CPU 等待狀態，由於查詢很少，因此 AAS 很高

    原因：CPU 繫結查詢 （複雜彙總、$regex)。

  • 徵狀：許多緩慢的查詢，但沒有顯示昂貴的 planSummary

    原因：外部瓶頸 （網路、限流、維護任務、查詢量）。

解決 — 修正問題

當您實作修正時，請務必使用 explain("executionStats") 驗證並監控 Performance Insights 資料庫負載。

  1. planSummary：「COLLSCAN」

    • 建立目標索引。

      範例：針對依 { category， price } 篩選並依價格遞減排序的頻繁查詢：

      
db.products.createIndex({ category: 1, price: -1 })

  2. 使用 $group / $sort 緩慢彙總

    • 提早推送 $match 和 $project，以減少流入 $group / $sort 的文件。

    • 儘早限制管道中的欄位數量：

      
db.products.explain("executionStats").aggregate([
  { $match: { category: "Electronics", price: { $gt: 0 } } },   // early filter
  { $project: { price: 1, category: 1 } },                     // reduce document size
  { $group: { _id: "$category", avgPrice: { $avg: "$price" } } }
])

  3. 高延遲，而績效詳情顯示依 IO 分組的資料庫負載等待

    • 驗證 BufferCacheHitRatio 是否低，或執行個體上的 ReadIOPS 是否高。增加執行個體記憶體 （升級執行個體類別，例如 r6g.large → r6g.xlarge) 或使用 NVMe 執行個體類別。

    • 減少索引足跡。

    • 新增僅供讀取複本以卸載讀取流量 （如果查詢可容忍最終一致性，請使用 readPreference 設定來重新導向複本上的流量）。

  4. PI 顯示 CPU 等待狀態，由於查詢很少，因此 AAS 很高

    • 以索引字首搜尋或 $text index 取代昂貴的 $regex。

    • 批次寫入 （插入） 以減少寫入放大。

注意

在提升生產變更之前，請務必在較低的環境中測試您的變更 （非生產）。