Explique los resultados

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 5.0, consulte Procedimientos de actualización de MongoDB.6.0

Para devolver información sobre los planes de consulta y las estadísticas de ejecución de los planes de consulta, MongoDB proporciona:

el db.collection.explain() método,
el método,cursor.explain() y
el explain comando.

Los resultados explain presentan los planes de consulta como un árbol de etapas.

"winningPlan" : {
   "stage" : <STAGE1>,
   ...
   "inputStage" : {
      "stage" : <STAGE2>,
      ...
      "inputStage" : {
         "stage" : <STAGE3>,
         ...
      }
   }
},

Cada etapa pasa sus resultados (es decir, documentos o claves de índice) al nodo principal. Los nodos hoja acceden a la colección o a los índices. Los nodos internos manipulan los documentos o las claves de índice resultantes de los nodos secundarios. El nodo raíz es la etapa final de la que MongoDB deriva el conjunto de resultados.

Las etapas son descriptivas de la operación; por ejemplo:

COLLSCAN para un escaneo de colección
IXSCAN para el escaneo de claves de índice
FETCH para la recuperación de documentos
SHARD_MERGE para combinar resultados de fragmentos
SHARDING_FILTER para el filtrado de documentos huérfanos de los fragmentos

Explicar la salida

Las siguientes secciones presentan una lista de algunos campos clave devueltos por la operación explain.

Nota

La lista de campos no pretende ser exhaustiva, sino resaltar algunos cambios de campos clave con respecto a versiones anteriores de Explain.
El formato de salida está sujeto a cambios entre versiones.

`queryPlanner`

La información de queryPlanner detalla el plan seleccionado por el optimizador del query.

Para colecciones no particionadas, explain devuelve la siguiente información queryPlanner:

"queryPlanner" : {
   "plannerVersion" : <int>,
   "namespace" : <string>,
   "indexFilterSet" : <boolean>,
   "parsedQuery" : {
      ...
   },
   "queryHash" : <hexadecimal string>,
   "planCacheKey" : <hexadecimal string>,
   "optimizedPipeline" : <boolean>, // Starting in MongoDB 4.2, only appears if true
   "winningPlan" : {
      "stage" : <STAGE1>,
      ...
      "inputStage" : {
         "stage" : <STAGE2>,
         ...
         "inputStage" : {
            ...
         }
      }
   },
   "rejectedPlans" : [
      <candidate plan 1>,
      ...
   ]
}

Para las colecciones particionadas, explain incluye el planificador de queries principal y la información del servidor para cada partición a la que se accede en el campo shards:

"queryPlanner" : {
   "mongosPlannerVersion" : <int>,
   "winningPlan" : {
      "stage" : <STAGE1>,
      "shards" : [
         {
            "shardName" : <string>,
            "connectionString" : <string>,
            "serverInfo" : {
               "host" : <string>,
               "port" : <int>,
               "version" : <string>,
               "gitVersion" : <string>
            },
            "plannerVersion" : <int>,
            "namespace" : <string>,
            "parsedQuery" : <document>,
            "queryHash" : <hexadecimal string>,
            "planCacheKey" : <hexadecimal string>,
            "optimizedPipeline" : <boolean>, // Starting in MongoDB 4.2, only appears if true
            "winningPlan" : {
               "stage" : <STAGE2>,
               "inputStage" : {
                  "stage" : <STAGE3>
                  ...,
               }
            },
            rejectedPlans: [
              <candidate plan1>,
            ]
         }
      ]
   }
}

explain.queryPlanner

Contiene información sobre la selección del plan del query por parte del optimizador del query.

explain.queryPlanner.namespace: Una string que especifica el namespace con los nombres de la base de datos y la colección a los que accede la query. El namespace tiene el formato <database>.<collection>.

explain.queryPlanner.indexFilterSet: Un valor booleano que especifica si MongoDB aplicó un filtro de índice para la forma de la consulta.

explain.queryPlanner.queryHash

Una cadena hexadecimal que representa el hash de la forma de consulta y depende únicamente de las formas de consulta. queryHash puede ayudar a identificar consultas lentas (incluido el filtro de consulta de operaciones de escritura) con la misma forma de consulta.

Nota

Como con cualquier función encriptada, dos formas del query diferentes pueden dar como resultado el mismo valor encriptado. Sin embargo, es poco probable que ocurran colisiones encriptadas entre diferentes formas del query.

Para obtener más información sobre queryHash y,planCacheKey consulte queryHash y.planCacheKey

Nuevo en la versión 4.2.

explain.queryPlanner.planCacheKey

Un hash de la clave para la entrada de caché del plan asociada con el query.

A diferencia queryHash de, depende tanto de la forma de la consulta como de los índices disponibles para ella. Es decir, si se añaden o eliminan índices compatibles con la forma de la consulta,planCacheKey el planCacheKey valor de podría cambiar, mientras que el queryHash de no cambiaría.

Para obtener más información sobre queryHash y,planCacheKey consulte queryHash y.planCacheKey

Nuevo en la versión 4.2.

explain.queryPlanner.optimizedPipeline

Un valor booleano que indica que toda la operación del pipeline de agregación se ha optimizado y, en su lugar, se ha completado mediante un árbol de etapas de ejecución del plan de queries.

Por ejemplo, la siguiente operación de agregación puede cumplirse mediante el árbol de ejecución del plan del query en lugar de usar el pipeline de agregación.

db.example.aggregate([ { $match: { someFlag: true } } ] )

El campo solo está presente si el valor es true y solo se aplica para explicar en las operaciones del pipeline de agregación. Cuando true, dado que el pipeline fue optimizado, no aparece información sobre la etapa de agregación en la salida.

Nuevo en la versión 4.2.

explain.queryPlanner.winningPlan

Un documento que detalla el plan seleccionado por el optimizador de consultas. MongoDB presenta el plan como un árbol de etapas; es decir, una etapa puede tener un o, si tiene varias etapas inputStage secundarias, inputStages un.

explain.queryPlanner.winningPlan.stage

Una string que indica el nombre de la etapa.

Cada etapa consiste en información específica de la etapa. Por ejemplo, una etapa IXSCAN incluirá los límites del índice junto con otros datos específicos del análisis de índice. Si una etapa tiene una etapa hija o varias etapas hijas, la etapa tendrá una inputStage o inputStages.

explain.queryPlanner.winningPlan.inputStage: Un documento que describe la etapa secundaria, que proporciona los documentos o claves de índice a su etapa principal. El campo está presente si la etapa principal tiene solo una secundaria.

explain.queryPlanner.winningPlan.inputStages: Una matriz de documentos que describe las etapas secundarias. Las etapas secundarias proporcionan los documentos o las claves de índice de la etapa principal. El campo está presente si la etapa principal tiene varios nodos secundarios. Por ejemplo, las etapas para expresiones $or o la intersección de índices consumen información de varias fuentes.

explain.queryPlanner.rejectedPlans: Arreglo de planes candidatos considerados y rechazados por el optimizador del query. El arreglo puede estar vacío si no hay otros planes candidatos.

`executionStats`

La información devuelta executionStats detalla la ejecución del plan ganador. Para incluir executionStats en los resultados, se debe ejecutar la explicación en:

executionStats o
Modo de verbosidad de allPlansExecution. Se puede utilizar el modo allPlansExecution para incluir los datos de ejecución parcial capturados durante la selección del plan.

Para colecciones no particionadas, explain devuelve la siguiente información executionStats:

"executionStats" : {
   "executionSuccess" : <boolean>,
   "nReturned" : <int>,
   "executionTimeMillis" : <int>,
   "totalKeysExamined" : <int>,
   "totalDocsExamined" : <int>,
   "executionStages" : {
      "stage" : <STAGE1>
      "nReturned" : <int>,
      "executionTimeMillisEstimate" : <int>,
      "works" : <int>,
      "advanced" : <int>,
      "needTime" : <int>,
      "needYield" : <int>,
      "saveState" : <int>,
      "restoreState" : <int>,
      "isEOF" : <boolean>,
      ...
      "inputStage" : {
         "stage" : <STAGE2>,
         "nReturned" : <int>,
         "executionTimeMillisEstimate" : <int>,
         ...
         "inputStage" : {
            ...
         }
      }
   },
   "allPlansExecution" : [
      {
         "nReturned" : <int>,
         "executionTimeMillisEstimate" : <int>,
         "totalKeysExamined" : <int>,
         "totalDocsExamined" :<int>,
         "executionStages" : {
            "stage" : <STAGEA>,
            "nReturned" : <int>,
            "executionTimeMillisEstimate" : <int>,
            ...
            "inputStage" : {
               "stage" : <STAGEB>,
               ...
               "inputStage" : {
                 ...
               }
            }
         }
      },
      ...
   ]
}

Para colecciones particionadas, explain incluye las estadísticas de ejecución de cada partición accedida.

"executionStats" : {
   "nReturned" : <int>,
   "executionTimeMillis" : <int>,
   "totalKeysExamined" : <int>,
   "totalDocsExamined" : <int>,
   "executionStages" : {
      "stage" : <STAGE1>
      "nReturned" : <int>,
      "executionTimeMillis" : <int>,
      "totalKeysExamined" : <int>,
      "totalDocsExamined" : <int>,
      "totalChildMillis" : <NumberLong>,
      "shards" : [
         {
            "shardName" : <string>,
            "executionSuccess" : <boolean>,
            "executionStages" : {
               "stage" : <STAGE2>,
               "nReturned" : <int>,
               "executionTimeMillisEstimate" : <int>,
               ...
               "chunkSkips" : <int>,
               "inputStage" : {
                  "stage" : <STAGE3>,
                  ...
                  "inputStage" : {
                     ...
                  }
               }
            }
         },
         ...
      ]
   }
   "allPlansExecution" : [
      {
         "shardName" : <string>,
         "allPlans" : [
            {
               "nReturned" : <int>,
               "executionTimeMillisEstimate" : <int>,
               "totalKeysExamined" : <int>,
               "totalDocsExamined" :<int>,
               "executionStages" : {
                  "stage" : <STAGEA>,
                  "nReturned" : <int>,
                  "executionTimeMillisEstimate" : <int>,
                  ...
                  "inputStage" : {
                     "stage" : <STAGEB>,
                     ...
                     "inputStage" : {
                       ...
                     }
                  }
               }
            },
            ...
         ]
      },
      {
         "shardName" : <string>,
         "allPlans" : [
          ...
         ]
      },
      ...
   ]
}

explain.executionStats

Contiene estadísticas que describen la ejecución del query completada para el plan ganador. Para las operaciones de guardado, la ejecución del query completada se refiere a las modificaciones que se realizarían, pero no aplica las modificaciones a la base de datos.

explain.executionStats.nReturned: Número de documentos devueltos por el plan del query ganador. nReturned corresponde al campo n devuelto por cursor.explain() en versiones anteriores de MongoDB.

explain.executionStats.executionTimeMillis

Tiempo total en milisegundos requerido para la selección del plan del query y la ejecución del query. Incluye el tiempo que se tarda en ejecutar la fase de prueba del proceso de selección del plan, pero no incluye el tiempo de red necesario para transmitir los datos de vuelta al cliente.

El tiempo reportado por explain.executionStats.executionTimeMillis no es necesariamente representativo del tiempo real del query. Durante las operaciones en estado estacionario (cuando el plan del query está almacenado en caché), o al usar cursor.hint() con cursor.explain(), MongoDB evita el proceso de selección del plan, lo que resulta en un tiempo real más rápido, llevando a un valor menor de explain.executionStats.executionTimeMillis .

explain.executionStats.totalKeysExamined: Número de entradas de índice escaneadas. totalKeysExamined corresponde al campo nscanned devuelto por cursor.explain() en versiones anteriores de MongoDB.

explain.executionStats.totalDocsExamined: Número de documentos examinados durante la ejecución del query. Las etapas comunes de ejecución del query que examinan documentos son COLLSCAN y FETCH.
Nota
totalDocsExamined se refiere al número total de documentos examinados y no al número de documentos devueltos. Por ejemplo, una etapa puede examinar un documento para aplicar un filtro. Si el documento es filtrado, entonces ha sido examinado pero no será devuelto como parte del conjunto de resultados del query.
Si un documento se examina varias veces durante la ejecución del query, totalDocsExamined cuenta cada examen. Es decir, totalDocsExamined no es un conteo del número total de documentos únicos examinados.

explain.executionStats.executionStages

Detalla la ejecución completa del plan ganador como un árbol de etapas; es decir, una etapa puede tener un inputStage o múltiples inputStages.

Cada etapa consta de información de ejecución específica para esa etapa.

explain.executionStats.executionStages.executionTimeMillisEstimate: El tiempo estimado en milisegundos para la ejecución de la query.

explain.executionStats.executionStages.works: Especifica el número de "unidades de trabajo" realizadas por la etapa de ejecución del query. La ejecución del query divide su trabajo en pequeñas unidades. Una "unidad de trabajo" puede consistir en examinar una única clave de índice, obtener un único documento de la colección, aplicar una proyección a un único documento o realizar una parte de la contabilidad interna.

explain.executionStats.executionStages.advanced: La cantidad de resultados intermedios devueltos o avanzados por esta etapa a su etapa principal.

explain.executionStats.executionStages.needTime: Número de ciclos de trabajo que no avanzaron un resultado intermedio a su etapa principal (véaseexplain.executionStats.executionStages.advanced). Por ejemplo, una etapa de escaneo de índice puede dedicar un ciclo de trabajo a buscar una nueva posición en el índice en lugar de devolver una clave de índice; este ciclo de trabajo se contabilizaría comoexplain.executionStats.executionStages.needTimeen lugar deexplain.executionStats.executionStages.advanced.

explain.executionStats.executionStages.needYield: La cantidad de veces que la capa de almacenamiento solicitó que la etapa de consulta suspendiera el procesamiento y liberara sus bloqueos.

explain.executionStats.executionStages.saveState: El número de veces que la etapa de query suspendió el Procesamiento y guardó su estado de ejecución actual, por ejemplo, en preparación para ceder sus bloqueos.

explain.executionStats.executionStages.restoreState: El número de veces que la etapa del query realizó la restauración de un estado de ejecución guardado, por ejemplo, recuperando los bloqueos que había cedido anteriormente.

explain.executionStats.executionStages.isEOF

Especifica si la etapa de ejecución ha alcanzado el final del flujo de datos:

Si true o 1, la etapa de ejecución ha alcanzado el final del flujo.
Si false o 0, la etapa aún puede tener resultados para devolver. Por ejemplo, considere un query con un límite cuyas etapas de ejecución consisten en una etapa LIMIT con una etapa de entrada de IXSCAN para el query. Si el query devuelve más del límite especificado, la etapa LIMIT informará isEOF: 1, pero su etapa subyacente IXSCAN informará isEOF: 0.

explain.executionStats.executionStages.inputStage.keysExamined

En las etapas de ejecución de consultas que escanean un índice (p. ej., IXSCAN), keysExamined es el número total de claves dentro y fuera de los límites que se examinan durante el escaneo del índice. Si el escaneo del índice consta de un único rango contiguo de claves, solo se deben examinar las claves dentro de los límites. Si los límites del índice constan de varios rangos de claves, el proceso de ejecución del escaneo del índice puede examinar las claves fuera de los límites para saltar del final de un rango al principio del siguiente.

Considere el siguiente ejemplo, donde hay un índice del campo x y la colección contiene 100 documentos con x valores 1 a 100:

db.keys.find( { x : { $in : [ 3, 4, 50, 74, 75, 90 ] } } ).explain( "executionStats" )

La consulta escaneará las claves 3 y 4. Luego, escaneará la clave 5, detectará que está fuera de los límites y saltará a la siguiente clave 50.

Continuando con este proceso, la consulta escanea las claves 3, 4, 5, 50, 51, 74, 75, 76, 90 y 91. Las claves 5, 51, 76 y 91 son claves fuera de límites que aún se examinan. El valor de keysExamined es 10.

explain.executionStats.executionStages.inputStage.docsExamined

Especifica el número de documentos escaneados durante la etapa de ejecución de la query.

Presente para la etapa COLLSCAN, así como para las etapas que recuperan documentos de la colección (por ejemplo, FETCH)

explain.executionStats.executionStages.inputStage.seeks: Novedad en la 3.4 versión: Solo paraIXSCAN etapas de escaneo de índice ().
El número de veces que tuvimos que mover el cursor del índice a una nueva posición para completar el escaneo del índice.

explain.executionStats.allPlansExecution: Contiene información parcial de ejecución capturada durante la fase de selección de planes para los planes ganadores y rechazados. El campo solo está presente si explain se ejecuta en la moda de nivel de verbosidad allPlansExecution.

Estadísticas del plan de ejecución para la consulta con `$lookup` la etapa de canalización

Nuevo en la versión 5.0.

Los resultados de explain pueden incluir estadísticas de ejecución para queries que utilizan una etapa de $lookup del pipeline. Para incluir esas estadísticas de ejecución, se debe Ejecutar la Operación 'explain' en uno de estos niveles de verbosidad de ejecución:

Los siguientes campos se incluyen en los resultados de explicación para un query $lookup :

'$lookup': {
   from: <string>,
   as: <string>,
   localField: <string>,
   foreignField: <string>
},
totalDocsExamined: <long>,
totalKeysExamined: <long>,
collectionScans: <long>,
indexesUsed: [ <string_1>, <string_2>, ..., <string_n> ],
executionTimeMillisEstimate: <long>

Para ver las descripciones de los campos en la sección $lookup, consulte la página $lookup.

Los otros campos son:

explain.totalDocsExamined: Número de documentos examinados durante la ejecución del query.

explain.totalKeysExamined: Número de claves de índice examinadas.

explain.collectionScans: Número de veces que se produjo un escaneo de colección durante la ejecución del query. Durante un escaneo de colección, cada documento en una colección se compara con el predicado del query. Los escaneos de colección ocurren si no existe un índice apropiado que cubra el query.

explain.indexesUsed: Arreglo de strings con los nombres de los índices utilizados por el query.

explain.executionTimeMillisEstimate: Tiempo estimado en milisegundos para la ejecución de los queries.

`serverInfo`

Para las colecciones no particionadas, explain devuelve la siguiente información serverInfo para la instancia de MongoDB:

"serverInfo" : {
   "host" : <string>,
   "port" : <int>,
   "version" : <string>,
   "gitVersion" : <string>
}

Para las colecciones particionadas, explain devuelve el serverInfo para cada partición a la que se accede y un objeto serverInfo de nivel superior para el mongos.

"queryPlanner" : {
   ...
   "winningPlan" : {
      "stage" : <STAGE1>,
      "shards" : [
         {
            "shardName" : <string>,
            "connectionString" : <string>,
            "serverInfo" : {
               "host" : <string>,
               "port" : <int>,
               "version" : <string>,
               "gitVersion" : <string>
            },
            ...
         }
         ...
      ]
   }
 },
 "serverInfo" : {      // serverInfo for mongos
   "host" : <string>,
   "port" : <int>,
   "version" : <string>,
   "gitVersion" : <string>
 }
 ...

3.0 Cambio de formato

A partir de MongoDB 3.0, el formato y los campos de los resultados explain han cambiado con respecto a versiones anteriores. A continuación, se enumeran algunas diferencias clave.

Escaneo de colecciones vs. uso de índices

Si el planificador de queries selecciona un escaneo de colección, el resultado de explain incluye una etapa COLLSCAN.

Si el planificador del query selecciona un índice, el resultado de la explicación incluye una etapa IXSCAN. La etapa incluye información como el patrón de claves del índice, la dirección de recorrido y los límites del índice.

En versiones anteriores de MongoDB, cursor.explain() devolvía el campo cursor con el valor de:

BasicCursor para escaneos de colecciones y
BtreeCursor <index name> [<direction>] para escaneos de índice.

Para obtener más información sobre las estadísticas de ejecución de los análisis de recopilación frente a los análisis de índice, consulte Analizar el rendimiento de las consultas.

Consultas cubiertas

Cuando un índice cubre un query, MongoDB puede tanto hacer coincidir las condiciones del query como devolver los resultados utilizando solo las claves del índice. MongoDB no necesita examinar documentos de la colección para realizar ninguna parte del query.

Cuando un índice cubre un query, el resultado de la explicación tiene una etapa IXSCAN que no es descendiente de una etapa FETCH, y en el executionStats, el totalDocsExamined es 0.

En versiones anteriores de MongoDB, cursor.explain() devolvía el campo indexOnly para indicar si el índice cubría una consulta.

Intersección del índice

Para un plan de intersección de índices, el resultado incluirá una AND_SORTED etapa o una AND_HASH etapa con una inputStages matriz que detalla los índices; por ejemplo:

{
   "stage" : "AND_SORTED",
   "inputStages" : [
      {
         "stage" : "IXSCAN",
         ...
      },
      {
         "stage" : "IXSCAN",
         ...
      }
   ]
}

En versiones anteriores de MongoDB, cursor.explain() devolvía el campo cursor con el valor de Complex Plan para las intersecciones de índice.

`$or` expresión

Si MongoDB utiliza índices para una expresión $or, el resultado incluirá la etapa OR con un arreglo inputStages que detalla los índices; por ejemplo:

{
   "stage" : "OR",
   "inputStages" : [
      {
         "stage" : "IXSCAN",
         ...
      },
      {
         "stage" : "IXSCAN",
         ...
      },
      ...
   ]
}

En versiones anteriores de MongoDB, cursor.explain() devolvía el arreglo clauses que detallaba los índices.

`$sort` y `$group` Etapas

Cuando explain se ejecuta en moda de nivel de verbosidad executionStats o allPlansExecution, las etapas $sort y $group tienen salida adicional.

Etapa	Campo	Tipo	Descripción
`$sort`	`totalDataSizeSortedBytesEstimate`	long	Un número estimado de bytes procesados en la etapa `$sort`.
`$sort`	`usedDisk`	booleano	Si la etapa `$sort` escribió en el disco.
`$group`	`totalOutputDataSizeBytes`	long	Una estimación del tamaño total de todos los documentos generados por la etapa en `$group` bytes.
`$group`	`usedDisk`	booleano	Si la etapa `$group` escribió en el disco.

Etapa de ordenamiento

Si MongoDB no puede usar uno o más índices para obtener el orden de ordenación, los resultados incluyen una etapa SORT que indica una operación de ordenación por bloqueo. Las ordenaciones por bloqueo no bloquean las operaciones concurrentes en la colección o la base de datos. El nombre se refiere al requisito de que la etapa SORT lea todos los documentos de entrada antes de devolver los de salida, bloqueando así el flujo de datos para esa consulta específica.

Si MongoDB requiere usar más de 100 megabytes de memoria del sistema para la ordenación por bloqueo, devuelve un error a menos que la consulta cursor.allowDiskUse() especifique. permite a MongoDB usar archivos temporales en disco para almacenar datos que excedencursor.allowDiskUse() el límite de megabytes de memoria del sistema 100 durante la ordenación por bloqueo. Si el plan de explicación no contiene una SORT etapa explícita, MongoDB puede usar un índice para obtener el orden de ordenación.

Volver

Analizar el rendimiento

Database Profiler

Explicar la salida

Nota

queryPlanner

Nota

executionStats

Nota

Estadísticas del plan de ejecución para la consulta con $lookup la etapa de canalización

serverInfo

3.0 Cambio de formato

Escaneo de colecciones vs. uso de índices

Consultas cubiertas

Intersección del índice

$or expresión

$sort y $group Etapas

Etapa de ordenamiento

`queryPlanner`

`executionStats`

Estadísticas del plan de ejecución para la consulta con `$lookup` la etapa de canalización

`serverInfo`

`$or` expresión

`$sort` y `$group` Etapas