利用查询解释 (Query Explain) 分析查询执行情况

本页面介绍了如何在执行查询时检索查询执行信息。

使用查询解释

您可以使用查询解释功能来了解查询的执行方式。这会提供可用于优化查询的详细信息。

您可以通过 Google Cloud 控制台或 explain 命令来使用查询解释。

控制台

在查询编辑器中执行查询，然后打开解释 标签页：

  1. 在 Google Cloud 控制台中，前往数据库页面。

    前往“数据库”

  2. 从数据库列表中，选择一个与 MongoDB 兼容的 Firestore 数据库。 控制台会为该数据库打开 Firestore Explorer 。 Google Cloud
  3. 在查询编辑器中输入查询，然后点击运行 。

  4. 点击解释标签页以查看查询分析输出。

    控制台中的“查询解释”标签页
MongoDB API

通过 explain 命令为 MongoDB API 中的查询解释提供支持，您可以在 Mongo Shell 和 Compass 等工具中使用该命令。

aggregate、find、distinct 和 count 命令支持 explain 命令，例如：

db.collection.explain('executionStats').find(...)

您还可以使用 explain() 方法，例如：

db.collection.find({QUERY}).explain('executionStats')
限制
请注意以下限制和差异：

  • 查询解释不支持返回游标的命令。例如，不支持通过直接调用以下命令来调用解释：

    db.collection.aggregate(..., explain: true)

  • 只有 find、aggregate、count、 distinct、update、delete 和 findAndModify 命令支持查询解释。

  • 查询解释支持 executionStats、allPlansExecution 和 queryPlanner 详细程度模式。

    • queryPlanner：仅返回执行计划，而不执行查询，
    • executionStats 和 allPlansExecution：返回执行计划以及结算、内存和执行统计信息。

    如果未指定详细程度模式，shell 会默认使用 queryPlanner。如需查看完整的执行统计信息，您必须指定 executionStats 或 allPlansExecution 详细程度模式。

分析

查询解释的输出包含两个主要组成部分：摘要统计信息和执行树。 请考虑以下查询示例：

db.orders.aggregate(
 [
   { "$match": { "user_id": 1234 } },
   { "$sort": { "date_placed": 1 } }
 ]
)

摘要统计信息

解释性输出的顶部包含执行统计信息的摘要。使用这些统计信息可确定查询是否具有高延迟或高费用。它还包含内存统计信息，可让您了解查询与内存限制的接近程度。

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

执行树

执行树会将查询执行描述为一系列节点。底部节点（叶节点）会从存储层检索数据，然后向上遍历树以生成查询响应。

如需详细了解每个执行节点，请参阅执行参考文档。

如需详细了解如何使用这些信息来优化查询，请参阅优化查询执行。

以下是执行树示例：

Execution:
 results returned: 35
 query id: 7e7b37ea1a259d79
 request peak memory usage: 45.56 KiB (46,656 B)
 data bytes read: 24.58 KiB (25,175 B)
 entity row scanned: 265

Billing:
 read units: 7

Tree:
• Compute
|  $out_1: map_set($record_1, "__id__", $__id___1, "__key__", unset)
|  is query result: true
|
|  Execution:
|   records returned: 35
|   latency: 204.87 ms (local 7.64 ms)
|
└── • Compute
    |  $__id___1: _id($__key___2)
    |
    |  Execution:
    |   records returned: 35
    |   latency: 197.23 ms (local 2.04 ms)
    |
    └── • MajorSort
        |  fields: [$v_5 ASC]
        |  output: [$__key___2, $record_1]
        |
        |  Execution:
        |   records returned: 35
        |   latency: 195.20 ms (local 28.42 ms)
        |   peak memory usage: 45.56 KiB (46,656 B)
        |
        └── • Compute
            |  $v_5: offset($v_4, 0L)
            |
            |  Execution:
            |   records returned: 35
            |   latency: 166.78 ms (local 14.84 ms)
            |
            └── • Compute
                |  $v_4: sortPaths(array($date_placed_1), [date_placed ASC])
                |
                |  Execution:
                |   records returned: 35
                |   latency: 151.94 ms (local 5.43 ms)
                |
                └── • TableScan
                       source: **/orders
                       order: STABLE
                       filter: $eq($user_id_1, 1,234)
                       output bindings: {$__key___2=row().__key__, $date_placed_1=row().date_placed, $record_1=row[* - { __create_time__, __update_time__ }](), $user_id_1=row().user_id}
                       output: [$__key___2, $date_placed_1, $record_1]

                       Execution:
                        records returned: 35
                        latency: 146.50 ms
                        data bytes returned: 3.25 KiB (3,325 B)
                        post-filtered rows: 230
                        records scanned: 265
                        data bytes read: 24.58 KiB (25,175 B)

后续步骤