Visual Explain — lea planes de un vistazo
Stage cards codificados por color, chips de cost ratio, y glyphs per-stage para que el peor stage de un plan salte a los ojos sin leer JSON.
Qué muestra
Cada plan de aggregation/find renderiza como un árbol de stage cards. Cada card lleva 4 señales visuales: una barra de accent coloreada de 4px a la izquierda (grade good/warn/bad), un glyph identificando el tipo de stage (ícono Key para IXSCAN, Warning para COLLSCAN, SortAscending para SORT, etc.), un chip con la ratio examined/returned cuando docsExamined está disponible, y un chip con el nombre del index para stages de la familia IXSCAN.
Cómo abrirlo
- Abra cualquier tab de workspace en una collection (Documents, Aggregation, etc.).
- Escriba su query en la Query Bar o construya un pipeline en el builder de Aggregation.
- Haga clic en "Explain" (top-right). El plan abre como un árbol.
- Hover cualquier chip de cost-ratio para ver POR QUÉ aquel stage obtuvo su grade (collection scan completo, baja selectivity, share dominante de tiempo, etc.).
Grades de costo
NoSqlStudio clasifica cada stage como good (eficiente), warn (probablemente desperdicio), o bad (definitivamente equivocado) — aplicado en orden de prioridad, primer match gana:
| Color | Significado | Disparador |
|---|---|---|
| 🟢 Verde | Stage eficiente | IXSCAN / EXPRESS_IXSCAN / IDHACK / FETCH |
| 🟡 Amarillo | Probablemente desperdicio — revise | COLLSCAN pequeño, SORT in-memory, baja selectivity de índice (<10%), stage domina >30% del tiempo total |
| 🔴 Rojo | Definitivamente equivocado — corrija antes de subir | COLLSCAN sobre >1000 docs, SORT in-memory excediendo threshold de 32MB |
Leyendo el chip de cost ratio
El chip muestra "examined → returned · X%" — el porcentaje de docs examinados que realmente volvieron. Regla de bolsillo:
- > 50%: índice tiene buena forma para esta query.
- 10–50%: borderline — puede ser aceptable para queries ad-hoc; reconstruya el índice para hot paths.
- < 10% con examined > 100: warn — índice tiene la forma equivocada (composite index faltando, sort order equivocada, etc.).
Ejemplo trabajado
Corra esta query contra una collection orders de 1M docs que no tiene composite index:
db.orders.find({ status: 'paid', userId: ObjectId('...') })Verá un card COLLSCAN rojo en la base del plan ("Full collection scan over >1000 documents — likely missing an index"). Cree un composite index en { status: 1, userId: 1 } y re-corra — el plan ahora muestra un IXSCAN verde con cost ratio de 99%.