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 el mismo plan. Planificar la forma de la consulta de caché.
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 de caché para una forma del query de caché de planes es Faltante:
| |
La entrada en la caché es una entrada de marcador de posición para esta forma. Es decir, el planificador ha visto la forma del query, ha calculado un valor que cuantifica la cantidad de trabajo requerida por el plan del query y ha almacenado la entrada del marcador de posición de la forma, pero la forma del query en caché del plan 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. |
Ver Vaciados de caché de plan para escenarios adicionales que activan cambios en el caché de 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.
planCacheShapeHash y planCacheKey
planCacheShapeHash
Para ayudar a identificar queries lentos con la misma forma del query de caché de planes, cada forma del query de caché de planes está asociada con un hash del query. El hash de la forma del query de la caché del plan es un 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.
A partir de MongoDB 8.0, el campo queryHash existente se duplica en un nuevo campo llamado planCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campo queryHash. Las versiones futuras de MongoDB removerán el campo queryHash obsoleto y deberás utilizar el campo planCacheShapeHash en su lugar.
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 planCacheShapeHash, 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/descartan índices que puedan soportar la forma del query, el valor planCacheKey puede cambiar, mientras que el valor planCacheShapeHash no cambiará.
A partir de MongoDB 8.0, el campo queryHash existente se duplica en un nuevo campo llamado planCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campo queryHash. Las versiones futuras de MongoDB removerán el campo queryHash obsoleto y deberás utilizar el campo planCacheShapeHash en su lugar.
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 planCacheShapeHash y planCacheKey están disponibles en:
campos de salida de explain():
A partir de MongoDB 8.0, el campo
queryHashexistente se duplica en un nuevo campo llamadoplanCacheShapeHash. Si estás utilizando una versión anterior de MongoDB, solo verás el campoqueryHash. Las versiones futuras de MongoDB removerán el campoqueryHashobsoleto y deberás utilizar el campoplanCacheShapeHashen su lugar.mensajes 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 establecen con el comando planCacheSetFilter y determinan qué índices evalúa el planificador para una forma del query. Una forma del query caché consiste en una combinación de especificaciones de query, ordenación y proyección. Si existe un filtro de índice para una forma del query dada, el planificador solo considera aquellos índices especificados en el filtro.
Cuando existe un filtro de índice para la forma del query de la caché del plan, MongoDB ignora el hint(). Para ver si MongoDB aplicó un filtro de índice para 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 a qué índices evalúa el planificador; el planificador aún puede seleccionar el escaneo de colección como el plan ganador para una determinada forma del query de caché de planes.
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.
A partir de MongoDB 8.0, utiliza la configuración de query en lugar de añadir filtros de índice. Los filtros de índice están en desuso a partir de MongoDB 8.0.
La configuración de queries tiene más funcionalidades que los filtros de índices. Además, los filtros de índice no son persistentes y no puedes crear fácilmente filtros de índice para todos los nodos del clúster. Para añadir ajustes de query y explorar ejemplos, consulta setQuerySettings.