Анализ выполнения запроса с помощью Query Explain

На этой странице описано, как получить информацию о выполнении запроса при его выполнении.

Используйте запрос Explain.

С помощью функции Query Explain вы можете понять, как выполняются ваши запросы. Это предоставит подробную информацию, которую вы сможете использовать для оптимизации ваших запросов .

Вы можете использовать Query Explain через консоль Google Cloud или команду explain .

Консоль

Выполните запрос в редакторе запросов и откройте вкладку «Пояснение» :

  1. В консоли Google Cloud перейдите на страницу «Базы данных» .

    Перейти к базам данных

  2. Из списка баз данных выберите базу данных Cloud Firestore . Консоль Google Cloud откроет Firestore Explorer для этой базы данных.
  3. Введите запрос в редакторе запросов и нажмите «Выполнить» .

  4. Чтобы просмотреть результаты анализа запроса, нажмите вкладку «Пояснение» .

    Вкладка «Объяснение запроса» в консоли.
API MongoDB

Функция Query Explain в API MongoDB поддерживается с помощью команды explain , которую можно использовать в таких инструментах, как Mongo Shell и Compass.

Команда explain поддерживается командами aggregate , find , distinct и count , например:

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

Вы также можете использовать метод explain() , например:

db.collection.find({QUERY}).explain('executionStats')
Ограничения
Обратите внимание на следующие ограничения и различия:

  • Query Explain не поддерживает команды, возвращающие курсор. Например, вызов explain путем прямого вызова следующей команды не поддерживается:

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

  • Функция Query Explain поддерживается только для команд find , aggregate , count , distinct , update , delete и findAndModify .

  • Query Explain поддерживает режимы детализации executionStats , allPlansExecution и queryPlanner .

    • queryPlanner : Возвращает только план выполнения запроса, без его фактического выполнения.
    • executionStats и allPlansExecution : Возвращают план выполнения вместе со статистикой по оплате, памяти и выполнению.

    Если режим детализации не указан, оболочка по умолчанию использует queryPlanner . Чтобы просмотреть полную статистику выполнения, необходимо указать режим детализации executionStats или allPlansExecution .

Анализ

Результат выполнения команды Query Explain содержит два основных компонента: сводную статистику и дерево выполнения. Рассмотрим следующий запрос в качестве примера:

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)

Что дальше?