MongoDB
Explica cuándo una consulta puede resolverse completamente desde un índice sin leer documentos y qué requisitos tienen filtro, proyección y campos multikey.
Una puede resolver filtro y projection utilizando únicamente un índice, sin leer los documentos de la colección. Esto elimina el stage y puede reducir I/O y latencia.
FETCHQuery:
db.orders.find(
{
businessId,
status: 'pending'
},
{
_id: 0,
createdAt: 1,
total: 1
}
).sort({ createdAt: -1 });Índice candidato:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
total: 1
});Para que una query sea cubierta:
_id debe excluirse si no forma parte del índice;query.explain('executionStats');Busca:
totalDocsExamined = 0
sin FETCHNo deduzcas cobertura solo por ver IXSCAN.
Un índice suele contener una representación más compacta que los documentos completos. Si el working set del índice cabe mejor en memoria, se reducen lecturas de páginas y deserialización.
Pero el beneficio depende de frecuencia, tamaño de documentos y selectividad.
Agregar campos únicamente para projection se conoce como extender el índice para cubrir una query.
Beneficio:
Costes:
No agregues diez campos grandes para cubrir una query poco frecuente.
MongoDB incluye _id por defecto:
{ total: 1 }Aunque no lo escribas, la salida incluye _id. Si el índice no lo contiene, puede requerir FETCH. Exclúyelo cuando no sea necesario:
{ _id: 0, total: 1 }La cobertura con índices multikey tiene restricciones. Si proyectas el propio array o la query requiere correlación de elementos, MongoDB puede necesitar FETCH.
Ejemplo:
{ businessId: 1, tags: 1 }Buscar por tags puede usar el índice, pero proyectar tags no siempre es cubierto debido a que las entradas de índice no reconstruyen necesariamente el array original.
Dot notation puede cubrir valores escalares anidados:
db.orders.createIndex({
businessId: 1,
'customer.nameAtPurchase': 1
});Query:
db.orders.find(
{ businessId },
{ _id: 0, 'customer.nameAtPurchase': 1 }
);Confirma siempre con explain; la forma de salida y restricciones pueden variar.
El índice y la query deben usar collation compatible. Una query case-insensitive con collation distinta puede no usar el índice esperado y perder cobertura.
Los índices representan valores según reglas específicas. Queries que distinguen missing, null o $exists pueden requerir leer documentos. No asumas que toda comparación sobre un campo indexado es cubierta.
En una colección sharded, el router puede necesitar información adicional para targeting o merge. La shard key y estructura del plan distribuido afectan si el flujo completo evita lecturas de documentos.
Una covered query puede reducir campos, pero no reemplaza autorización. El filtro sigue necesitando tenant y permisos:
{
businessId: session.businessId,
status: 'pending'
}Listado frecuente de órdenes:
const cursor = orders.find(
{
businessId,
status
},
{
projection: {
_id: 0,
createdAt: 1,
total: 1,
orderNumber: 1
}
}
).sort({ createdAt: -1 }).limit(20);Índice:
{
businessId: 1,
status: 1,
createdAt: -1,
orderNumber: 1,
total: 1
}Antes de extenderlo, mide si FETCH realmente es el cuello de botella. Si los documentos son pequeños y están en cache, el índice mayor puede costar más de lo que ahorra.
Es especialmente útil para:
Evítala como objetivo absoluto cuando:
_id;Una covered query elimina la lectura del documento, pero requiere que filtro, orden y salida vivan en un índice compatible. Es una optimización selectiva, no una meta universal. Confírmala con totalDocsExamined: 0 y ausencia de FETCH.
_id puede romper cobertura?Collations.