Para cualquier query dada, el planificador de query de MongoDB elige y guarda en caché el plan del query más eficiente dado los índices disponibles. Para evaluar la eficiencia de los planes del query, el planificador de consultas ejecuta todos los planes candidatos durante un período de prueba. En general, el plan ganador es el plan del query que produce el mayor número de resultados durante el periodo de prueba realizando la menor cantidad de trabajo.
La entrada de caché del plan asociado se utiliza para consultas posteriores con la misma forma de consulta.
El siguiente diagrama ilustra la lógica del planificador de query:
Nota
Utilizando explain ignora todas las entradas de caché de plan existentes y evita que el planificador de consultas MongoDB cree una nueva entrada de caché de plan.
Estado de la entrada de caché de planes
Cada forma del query de caché del plan está asociada a uno de los tres estados en la caché:
Estado | Descripción |
|---|---|
No hay ninguna entrada para esta forma en la caché. Para un query, si el estado de la entrada en caché para una forma del query es No disponible:
| |
La entrada en la caché es una entrada de marcador de posición para esta forma. Es decir, el planificador ha visto la forma, ha calculado un valor que cuantifica la cantidad de trabajo que requiere el plan y ha almacenado la entrada del marcador de posición de la forma, pero la forma del query no se utiliza para generar planes del query. Para una query, si el estado de la entrada en caché para una forma es Inactiva:
| |
La entrada en la caché es para el plan ganador. El planificador puede usar esta entrada para generar planes del query. Para una query, si el estado de la entrada en caché de una forma es Activo: La entrada activa se utiliza para generar planes del query. El planificador también evalúa el rendimiento de la entrada y, si su valor, que cuantifica la cantidad de trabajo requerido por el plan, ya no cumple con el criterio de selección, pasará al estado Inactivo. |
Consultar Vaciados de caché del plan para escenarios adicionales que activen el trigger de cambios en la caché del plan.
plan del query e información de caché
Para ver la información del plan del query para una query determinada, se puede usar db.collection.explain() o la cursor.explain() .
Para ver la información de la caché de planes de una colección, puedes utilizar la $planCacheStats etapa de agregación.
Planificar vaciados de caché
La caché del plan del query no persiste si un mongod se reinicia o se apaga. Además:
Cualquier evento DDL borra la caché del plan de la colección relevante. Algunos ejemplos de eventos DDL incluyen el borrado de una colección y la creación, borrado u ocultación de un índice.
El mecanismo de reemplazo de caché de menor uso reciente (LRU) elimina la entrada de caché menos recientemente accedida, sin importar el estado.
Los usuarios también pueden:
Borrar manualmente toda la caché del plan usando el método
PlanCache.clear().Borra manualmente entradas específicas de la caché del plan utilizando el método
PlanCache.clearPlansByQuery().
Límite de tamaño de la información de depuración del caché de planes
A partir de MongoDB,5.0 la caché del plan guardará plan cache entradas completas solo si el tamaño acumulado de plan caches para todas las colecciones es inferior a 0.5 GB. Cuando el tamaño acumulado de plan caches para todas las colecciones supera este umbral,plan cache se almacenan entradas adicionales sin la siguiente información de depuración:
El tamaño estimado en bytes de una entrada de plan cache está disponible en el resultado de $planCacheStats.
queryHash y planCacheKey
queryHash
Para identificar consultas lentas con la misma forma de consulta, cada una se asocia a un queryHash.queryHash es una cadena hexadecimal que representa un hash de la forma de consulta y depende únicamente de esta.
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.
planCacheKey
Para proporcionar más perspectiva sobre la caché del plan del query, MongoDB ofrece el planCacheKey.
planCacheKey es un hash de la forma del query de la caché del plan, que se distingue además por los índices disponibles para la forma.
Nota
A diferencia de queryHash, planCacheKey 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, el valor de planCacheKey podría cambiar, mientras que el de queryHash no cambiaría.
Por ejemplo, considere una colección foo con los siguientes índices:
db.foo.createIndex( { x: 1 } ) db.foo.createIndex( { x: 1, y: 1 } ) db.foo.createIndex( { x: 1, z: 1 }, { partialFilterExpression: { x: { $gt: 10 } } } )
Las siguientes queries en la colección tienen la misma estructura:
db.foo.explain().find( { x: { $gt: 5 } } ) // Query Operation 1 db.foo.explain().find( { x: { $gt: 20 } } ) // Query Operation 2
Dadas estas queries, el índice con la expresión de filtro parcial puede dar soporte a la operación de query 2 pero no puede dar soporte a la operación de query 1. Dado que los índices disponibles para soportar la operación query 1 difieren de la operación query 2, las dos querys tienen planCacheKey diferentes.
Si se descartara uno de los índices o si se añadiera un nuevo índice { x: 1, a: 1
}, el planCacheKey para ambas operaciones de query cambiará.
Disponibilidad
Los queryHash y planCacheKey están disponibles en:
Campos desalida de explain():
queryPlanner.queryHashyqueryPlanner.planCacheKeymensajes de registro del perfilador y mensajes de registro de diagnóstico (es decir, mensajes de registro de mongod/mongos) al registrar queries lentas.
$planCacheStatsetapa de agregaciónPlanCache.listQueryShapes()método/planCacheListQueryShapescomandoPlanCache.getPlansByQuery()método/planCacheListPlanscomando
Filtros de índices
Los filtros de índice se configuran con el planCacheSetFilter comando y determinan qué índices evalúa el optimizador para una forma de consulta. Una forma de consulta se compone de una combinación de especificaciones de consulta, ordenación y proyección. Si existe un filtro de índice para una forma de consulta determinada, el optimizador solo considera los índices especificados en el filtro.
Cuando existe un filtro de índice para la forma de consulta, MongoDB ignora elhint(). Para comprobar si MongoDB aplicó un filtro de índice a una forma de consulta, revise el campoindexFilterSetdel métododb.collection.explain()ocursor.explain().
Los filtros de índice solo afectan los índices que evalúa el optimizador; el optimizador aún puede seleccionar el escaneo de colección como el plan ganador para una forma de consulta determinada.
Los filtros de índice existen durante el proceso del servidor y no se mantienen después del apagado. MongoDB también proporciona un comando para remover manualmente los filtros.
Debido a que los filtros de índice anulan el comportamiento esperado del optimizador, así como el hint() método, utilice los filtros de índice con moderación.
A partir de MongoDB 6.0, un filtro de índice utiliza la intercalación establecida previamente mediante el comando planCacheSetFilter.