Analisar a execução de consultas com o Query Explain

Esta página descreve como recuperar informações de execução de consultas ao executar uma consulta.

Usar o Query Explain

Use o Query Explain para entender como suas consultas estão sendo executadas. Isso fornece detalhes que podem ser usados para otimizar suas consultas.

É possível usar a explicação de consultas no console Google Cloud ou com o comando explain.

Console

Execute uma consulta no Editor de consultas e abra a guia Explicação:

  1. No console do Google Cloud , acesse a página Bancos de dados.

    Acessar "Bancos de dados"

  2. Na lista de bancos de dados, selecione um banco de dados do Firestore com compatibilidade com o MongoDB. O console Google Cloud abre o Firestore Explorer para esse banco de dados.
  3. Insira uma consulta no editor e clique em Executar.

  4. Clique na guia Explicação para conferir a saída da análise de consulta.

    A guia "Query Explain" no console
API MongoDB

A explicação de consultas na API MongoDB é compatível com o comando explain que pode ser usado em ferramentas como o Mongo Shell e o Compass.

O comando explain é compatível com os comandos aggregate, find, distinct e count. Por exemplo:

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

Você também pode usar o método explain(), por exemplo:

db.collection.find({QUERY}).explain('executionStats')
Limitações
Observe as seguintes limitações e diferenças:

  • O Query Explain não é compatível com comandos que retornam um cursor. Por exemplo, não é possível invocar a explicação chamando o seguinte comando diretamente:

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

  • A explicação de consultas só é compatível com os comandos find, aggregate, count, distinct, update, delete e findAndModify.

  • A explicação de consultas é compatível com os modos de detalhamento executionStats, allPlansExecution e queryPlanner.

    • queryPlanner: retorna apenas o plano de execução, sem executar a consulta.
    • executionStats e allPlansExecution: retornam o plano de execução com estatísticas de faturamento, memória e execução.

    Se nenhum modo de verbosidade for especificado, o shell vai usar queryPlanner como padrão. Para conferir as estatísticas de execução completas, especifique o modo de detalhamento executionStats ou allPlansExecution.

Análise

A saída do Query Explain contém dois componentes principais: as estatísticas de resumo e a árvore de execução. Considere esta consulta como exemplo:

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

Estatísticas de resumo

A parte de cima da saída explicada contém um resumo das estatísticas de execução. Use essas estatísticas para determinar se uma consulta tem alta latência ou custo. Além disso, contém estatísticas de memória que informam se a consulta está próxima dos limites de memória.

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

Árvore de execução

A árvore de execução descreve a execução da consulta como uma série de nós. Os nós inferiores (nós folha) recuperam dados da camada de armazenamento, que percorre a árvore para gerar uma resposta de consulta.

Para detalhes sobre cada nó de execução, consulte a Referência de execução.

Para saber como usar essas informações para otimizar suas consultas, consulte Otimizar a execução de consultas.

Confira um exemplo de árvore de execução:

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)

A seguir