MongoDB
Introducción a los índices de MongoDB: B-tree, selectividad, cobertura, costos de escritura, memoria y relación entre query shape y orden de claves.
Un índice es una estructura ordenada que permite localizar documentos sin examinar toda la colección. MongoDB mantiene claves extraídas de los documentos junto con referencias a ellos.
query
↓
index bounds
↓
claves candidatas
↓
documentos necesariosUn índice acelera determinadas query shapes, pero consume almacenamiento, memoria y trabajo en cada inserción, actualización y eliminación.
Sin índice, una consulta puede ejecutar COLLSCAN:
leer documento 1
leer documento 2
...
leer documento NCon un índice compatible, MongoDB puede recorrer solo un rango de claves:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1
});Query:
db.orders.find({
businessId,
status: 'pending'
}).sort({ createdAt: -1 }).limit(20);Un índice no “acelera la colección”. Sirve operaciones concretas.
access pattern
→ filter + sort + projection
→ índice candidato
→ explain
→ coste de lectura y escrituraCrear índices por intuición produce estructuras redundantes y costosas.
Los índices generales utilizan una estructura ordenada. Esto permite:
El orden de campos en un compound index es parte del contrato.
Toda colección normal tiene un índice unique sobre _id. Permite identificar documentos, pero no sirve automáticamente a queries por tenant, estado o fecha.
Buscar por _id sin businessId tampoco sustituye autorización.
db.products.createIndex({ barcode: 1 });Es adecuado cuando la query principal filtra por ese campo. Si el barcode es único por negocio, un compound unique index puede reflejar mejor la regla:
db.products.createIndex(
{ businessId: 1, barcode: 1 },
{ unique: true }
);{ businessId: 1, status: 1, createdAt: -1 }Puede servir filtros y sort combinados. Sus prefijos importan:
businessId
businessId + status
businessId + status + createdAtNo ofrece el mismo acceso eficiente para una query solo por createdAt.
Un campo selectivo reduce mucho el conjunto. active: true puede coincidir con casi todos los documentos; businessId + sku puede localizar uno.
La selectividad no decide sola el orden: también importan sort, rangos, prefix usage y distribución.
Un índice compatible puede entregar resultados ya ordenados. Si no, MongoDB puede ejecutar un sort en memoria o disco.
db.orders.createIndex({
businessId: 1,
createdAt: -1,
_id: -1
});Soporta un listado por negocio en orden descendente. La dirección completa puede recorrerse en sentido inverso, pero combinaciones parciales deben verificarse.
Si filtro y campos devueltos están en el índice, una query puede ser covered. Añadir campos únicamente para cubrir aumenta tamaño y write amplification. Debe justificarse por frecuencia y beneficio medido.
Cada insert debe actualizar todos los índices relevantes. Cada update que cambia un campo indexado modifica claves. Cada delete elimina entradas.
Demasiados índices generan:
Las partes activas de los índices compiten por cache. Que el dataset total no quepa en RAM no implica fallo, pero un working set de índices demasiado grande aumenta I/O y evictions.
Cada tipo responde a una necesidad distinta.
Un índice hidden puede mantenerse sin ser elegible normalmente por el planner. Sirve para evaluar el impacto de retirarlo antes de eliminarlo, según soporte de versión.
Sigue consumiendo escritura y almacenamiento mientras está hidden.
Si existen:
{ businessId: 1 }
{ businessId: 1, status: 1 }el compound puede cubrir algunas queries del índice corto por prefix. Pero unicidad, sparse/partial, collation y uso de sort pueden impedir considerarlo redundante automáticamente.
Revisa uso real antes de eliminar.
Crear un índice sobre una colección grande consume CPU, I/O y espacio. El comportamiento online, impacto y opciones dependen de versión y topología.
Planifica:
Una query rápida con cien documentos no demuestra nada. Prueba:
Los índices interactúan con shard key y targeting. Una query bien indexada pero sin shard key puede ejecutarse en múltiples shards. Un unique index en colección sharded tiene reglas adicionales.
Aumenta coste sin servir query shapes completas.
Puede ser peor que un compound diseñado para filtro y sort.
String y ObjectId crean claves distintas.
Puede no resolver el plan real.
Consume recursos permanentemente.
Una query cacheada puede parecer rápida mientras examina demasiadas claves.
explain('executionStats').Un índice intercambia coste de escritura y memoria por acceso eficiente. Su unidad de diseño es la query shape, no el campo individual. Todo índice debe tener un propósito verificable, métricas de uso y una estrategia de lifecycle.
Índices compuestos y ESR.