MongoDB
Explica cómo ordenar claves en índices compuestos siguiendo equality, sort y range, y cómo adaptar ESR a las consultas reales y su selectividad.
Un índice compuesto contiene varias claves en un orden definido. Ese orden determina qué filtros, rangos, sorts y prefijos puede resolver eficientemente.
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
_id: -1
});No es una colección de índices independientes. Es una secuencia ordenada por businessId, después status, después createdAt y finalmente _id.
Una query real suele combinar condiciones:
db.orders.find({
businessId,
status: 'pending',
createdAt: { $gte: start, $lt: end }
}).sort({ createdAt: -1, _id: -1 });Índices separados en businessId, status y createdAt no siempre sirven tan bien como un compound que representa la query shape completa.
El índice:
{ a: 1, b: 1, c: 1 }tiene prefijos útiles:
a
a + b
a + b + cUna query solo por b no puede saltar directamente al mismo rango que una query por a. Algunas versiones y planes pueden aplicar estrategias adicionales, pero no diseñes suponiendo acceso equivalente sin explain().
La guía ESR propone:
Equality
→ Sort
→ RangeEjemplo:
{ businessId: 1, status: 1, createdAt: -1 }businessId y status: equality;createdAt: sort o range.ESR es una heurística, no una ley universal. Debes considerar:
Las condiciones de igualdad fijan un prefijo:
{ businessId, status: 'pending' }El orden entre varios equality fields puede tener menos impacto para una única query, pero afecta prefixes, otras queries, compresión y reglas como shard key o uniqueness.
No ordenes campos solo por “el más selectivo primero” sin revisar el conjunto de access patterns.
Para soportar sort, los campos anteriores deben estar fijados de forma compatible.
Índice:
{ businessId: 1, status: 1, createdAt: -1, _id: -1 }Query:
{ businessId, status: 'pending' }Sort:
{ createdAt: -1, _id: -1 }Puede recorrerse ordenadamente. Si omites status del filtro, el orden global por createdAt puede no estar disponible de la misma forma porque existen bloques por status.
Un índice { a: 1, b: -1 } puede recorrerse en sentido inverso para { a: -1, b: 1 }. No soporta necesariamente { a: 1, b: 1 } con el mismo orden.
Verifica combinaciones exactas.
Un rango restringe la capacidad de usar campos posteriores para sort y bounds de forma ideal.
{
createdAt: { $gte: start, $lt: end }
}Después del primer campo de rango, los siguientes campos pueden utilizarse de manera limitada para filtering o sort según shape. Por eso ESR coloca sort antes de range cuando evitar el sort es prioritario.
Cuando el rango es muy selectivo y el sort pequeño, puede convenir Equality–Range–Sort. El servidor filtra pocos documentos y ordenarlos puede ser barato.
No decidas por siglas: compara ambos planes con datos representativos.
$in puede comportarse como múltiples equality values o como un rango amplio dependiendo de cantidad y contexto. Los umbrales y optimizaciones pueden cambiar por versión.
Limita listas enviadas por usuarios y verifica plan con cardinalidades reales.
{ businessId: 1, status: 1, createdAt: -1, _id: -1 }El tie-breaker _id permite cursor pagination estable. El cursor usa los mismos campos y direcciones del sort.
Supón:
Probablemente necesitan índices distintos:
{ businessId: 1, status: 1, createdAt: -1, _id: -1 }
{ businessId: 1, orderNumber: 1 }
{ businessId: 1, 'customer.id': 1, createdAt: -1 }No intentes construir un índice gigante que sirva todo; puede no servir bien nada y aumenta escrituras.
MongoDB puede combinar índices en algunos planes. No depende de ello como sustituto de un compound crítico. Intersection puede examinar más claves y no resolver sort tan bien.
Añadir campos de salida al final puede cubrir:
{ businessId: 1, status: 1, createdAt: -1, total: 1 }Pero aumenta tamaño. Evalúa frecuencia y totalDocsExamined.
status: 'pending' puede ser selectivo globalmente, pero un tenant outlier puede tener millones de pendientes. Estadísticas promedio no representan todas las claves.
Prueba valores comunes, raros y extremos.
La collation forma parte del índice. Un compound con strings no sirve igual a queries con collation incompatible. También cambia unique semantics.
Si un campo del compound es array, el índice se vuelve multikey. Existen restricciones cuando varios campos son arrays y para sort/coverage. El schema debe conocerse antes de crear el índice.
Access pattern:
Listar 20 órdenes pending de una sucursal
filtro: businessId + branchId + status
sort: createdAt DESC + _id DESCÍndice:
{
businessId: 1,
branchId: 1,
status: 1,
createdAt: -1,
_id: -1
}Validación:
db.orders.find(filter)
.sort(sort)
.limit(20)
.explain('executionStats');Revisa que keys/docs examined estén cerca de resultados y no exista sort bloqueante.
Ignora selectividad y otras shapes.
Aumenta coste y prefixes inútiles.
Dirección y orden importan.
Campos posteriores pierden utilidad.
El plan puede comportarse distinto con skew.
No sustituye el índice del hot path.
El orden de un compound index define su utilidad. ESR es una guía para razonar sobre igualdad, orden y rangos, no una receta. El índice correcto es el que sirve una query shape crítica con coste total aceptable y resultados verificados.
Multikey indexes.