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 en la caché del plan asociada se utiliza para subsequent queries con la misma forma del query.
El siguiente diagrama ilustra la lógica del planificador de query:
Nota
El uso de explain ignora todas las entradas existentes en la caché del plan e impide que el planificador de query de MongoDB cree una nueva entrada en la caché del 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 un query, si el estado de la entrada de caché para 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 requerida 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é de planes guardará entradas completas de plan cache 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 la plan caches para todas las colecciones supera este umbral, se almacenan entradas adicionales de plan cache 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 ayudar a identificar consultas lentas con la misma forma del query, cada forma del query está asociada a un queryHash. El queryHash es una string hexadecimal que representa un hash de la forma del query y depende únicamente de la forma del query.
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 del queryHash, el planCacheKey es una función tanto de la forma del query como de los Ãndices disponibles actualmente para la forma. Es decir, si se añaden o descartan Ãndices que puedan soportar la forma del query, el valor planCacheKey puede cambiar, mientras que el valor 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 de la salida 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 Ãndices se configuran con el comando planCacheSetFilter y determinan qué Ãndices evalúa el planificador para una forma del query. Una forma del query consiste en una combinación de especificaciones de query, ordenamiento y proyección. Si existe un filtro de Ãndice para una determinada forma del query, el planificador solo considera los Ãndices especificados en el filtro.
Cuando existe un filtro de Ãndice para la forma del query, MongoDB ignora el hint(). Para ver si MongoDB aplicó un filtro de Ãndice a una forma del query, revisa el campo indexFilterSet de cualquiera de los métodos db.collection.explain() o cursor.explain().
Los filtros de Ãndice solo afectan qué Ãndices evalúa el planificador; el planificador puede seguir seleccionando el escaneo de la colección como el plan ganador para una determinada forma del query.
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.
Dado que los filtros de Ãndice anulan el comportamiento esperado del planificador, asà como el método hint(), utilizar 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.