MongoDB
Interpreta explain() mediante executionStats, documentos y claves examinadas, stages, tiempo, sort y cobertura para diagnosticar consultas MongoDB.
permite observar cómo MongoDB planea y ejecuta una consulta. No optimiza por sí mismo: entrega evidencia para comparar query shape, índice, cardinalidad y coste.
explain()db.orders.find({
businessId,
status: 'pending'
}).sort({ createdAt: -1 }).limit(20)
.explain('executionStats');Muestra winning plan, rejected plans e información de planificación sin ejecutar completamente la query como una operación normal.
Ejecuta el winning plan y devuelve métricas reales, entre ellas documentos retornados, keys y documents examinados.
Incluye información de evaluación de candidatos. Úsalo para diagnóstico específico; genera más información y no debe ejecutarse indiscriminadamente en producción.
Documentos devueltos.
Entradas de índice recorridas.
Documentos leídos.
Tiempo observado en esa ejecución. Puede variar por cache, carga, red interna y hardware; no lo interpretes aislado.
Relación útil:
keys examined / returned
docs examined / returnedCuanto mayor sea la diferencia, más trabajo residual existe.
nReturned = 20
totalKeysExamined = 20
totalDocsExamined = 20No garantiza perfección, pero indica buen targeting.
nReturned = 20
totalKeysExamined = 250000
totalDocsExamined = 100000Puede deberse a índice incorrecto, range amplio, filtro residual, sort o datos sesgados.
Comienza desde la raíz y sigue el input stage:
LIMIT
└── FETCH
└── IXSCANInterpretación:
Otro ejemplo:
SORT
└── COLLSCANLa colección se recorre y después se ordena; suele ser costoso en un hot path.
En IXSCAN, revisa indexBounds. Permiten saber si MongoDB recorre un intervalo preciso o gran parte del índice.
Un índice elegido puede tener bounds amplios por falta de igualdad en el prefijo.
Si parte de la condición aparece en FETCH, el índice produjo candidatos que luego se descartan. Puede ser aceptable si son pocos; problemático si son millones.
Busca un stage SORT o evidencia de orden entregado por índice. Un sort en memoria puede dominar la latencia incluso con filtro indexado.
Una query cubierta suele presentar totalDocsExamined: 0 y no tener FETCH. Confirma también que projection y _id estén cubiertos.
db.orders.explain('executionStats').aggregate(pipeline);Revisa:
$lookup;Un explain de aggregation puede variar de forma entre versiones.
Operaciones de escritura también dependen del filtro. Puedes explicar formas compatibles para comprobar que un update masivo no hace scan completo. No ejecutes una escritura peligrosa solo para medirla; utiliza APIs y entornos seguros.
La primera ejecución puede leer disco; la siguiente puede aprovechar cache. Prueba ambas cuando sea relevante y no “calientes” artificialmente un benchmark sin documentarlo.
Una query por tenant pequeño puede tener buen plan y fallar con tenant outlier. Prueba:
No incluye necesariamente:
Combínalo con métricas de aplicación y profiler.
executionStats ejecuta trabajo real. Una query sin índice sobre una colección enorme puede afectar producción aunque solo quieras analizarla.
Medidas:
maxTimeMS;allPlansExecution por rutina.executionTimeMillis;IXSCAN suficiente;nReturned;explain() responde cuánto trabajo hace MongoDB y por qué. Las métricas deben interpretarse en relación con resultados y workload. Un plan se valida con cardinalidad, datos representativos, estabilidad y métricas externas, no por el nombre de un stage aislado.
Covered queries.