MongoDB
Compara índices unique, partial y sparse para imponer unicidad, indexar subconjuntos y controlar documentos sin campos, null y reglas condicionales.
Los índices , y no solo aceleran consultas: también controlan qué documentos participan y, en el caso unique, protegen una regla de unicidad bajo concurrencia.
db.products.createIndex(
{ businessId: 1, sku: 1 },
{ unique: true }
);Este índice protege que un mismo negocio no tenga dos productos con el mismo SKU, incluso cuando dos requests intentan insertarlos simultáneamente.
Un índice unique rechaza escrituras que producirían claves duplicadas.
{ businessId: 1, sku: 1 }La unicidad es de la combinación, no de sku globalmente.
Este patrón no basta:
buscar SKU
→ no existe
→ insertarDos requests pueden observar ausencia. El índice es la barrera real. La aplicación captura duplicate key y devuelve conflicto de dominio.
Crear un unique index falla si ya existen duplicados. Antes:
No elimines duplicados automáticamente sin comprender su significado.
La semántica de unique con null y campos ausentes puede sorprender. Un single-field unique index puede limitar cuántos documentos tienen null/missing según cómo se generan las claves.
Si el campo es optional y solo debe ser unique cuando existe, un partial unique index suele expresar mejor la intención.
Indexa únicamente documentos que cumplen una expresión:
db.products.createIndex(
{ businessId: 1, sku: 1 },
{
unique: true,
partialFilterExpression: {
deletedAt: null
}
}
);Solo los documentos que participan están sujetos al índice y a la unicidad.
Ejemplo: emails únicos solo cuando están verificados:
db.users.createIndex(
{ normalizedEmail: 1 },
{
unique: true,
partialFilterExpression: {
emailVerifiedAt: { $type: 'date' }
}
}
);La regla debe coincidir con el dominio. Permitir varios emails no verificados puede o no ser correcto.
MongoDB solo puede usar un partial index cuando la query garantiza que sus resultados pertenecen al subconjunto indexado.
Índice parcial:
{ active: true }Query compatible:
{ businessId, active: true }Query sin condición active no puede depender de un índice que omite inactivos, porque produciría resultados incompletos.
Un índice sparse omite documentos que no contienen el campo indexado.
db.users.createIndex(
{ phone: 1 },
{ sparse: true }
);Es menos expresivo que partial. No permite describir estados, tipos o combinaciones tan claramente.
sparse
→ principalmente presencia del campo
partial
→ expresión explícita sobre el documentoPartial suele ser preferible para diseños nuevos porque hace visible qué documentos participan.
Puede permitir múltiples documentos sin campo, mientras protege valores presentes según semántica exacta. Debes probar null, missing y tipos reales; no asumir equivalencia entre “ausente” y “no indexado”.
Problema:
producto A SKU X → soft deleted
crear producto B SKU XCon unique global, B falla. Con partial unique sobre activos, puede crearse.
Restaurar A después puede fallar porque B ocupa la clave. La política de restore debe contemplarlo.
La collation del índice define comparación:
db.users.createIndex(
{ normalizedEmail: 1 },
{
unique: true,
collation: {
locale: 'en',
strength: 2
}
}
);La query debe usar collation compatible para aprovecharlo. Para emails, además de collation debes definir una normalización de dominio; las reglas de email no son idénticas a lowercase genérico.
{ organizationId: 1, userId: 1 }Protege una membresía por organización y usuario. Puede incluir estado o usar partial para membresías activas.
No incluyas campos mutables en una identidad unique sin analizar updates y conflictos.
Unique multikey tiene semántica especial y no garantiza que dos elementos dentro del mismo array no compartan una propiedad. Para relaciones, una colección de asociación suele ofrecer una regla más clara.
En colecciones sharded, unique indexes tienen requisitos relacionados con la shard key. Verifica las reglas de la versión y el diseño antes de asumir unicidad global.
Una regla que no puede protegerse globalmente con el índice elegido puede necesitar cambiar shard key o modelado.
Para índices de rendimiento puedes probar hidden. Para unique, no puedes “probar” la garantía de la misma forma: introducirla requiere limpiar datos y coordinar writers.
Estrategia:
Puede quedar fuera en sparse/partial.
Puede participar y chocar.
String '123' y number 123 son claves distintas, creando duplicados lógicos.
Valores que el negocio considera iguales pueden no chocar.
Un update puede liberar la clave.
Puede producir duplicate key durante el cambio de estado.
No protege carreras.
El build falla.
La intención queda incompleta.
El índice no se usa.
Otros writers crean duplicados.
Soft delete y unique entran en conflicto.
Unique es una garantía concurrente; partial define un subconjunto explícito y sparse omite principalmente campos ausentes. La combinación correcta refleja scope, lifecycle y tipos del dominio. La aplicación debe manejar conflictos sin sustituir la garantía del servidor.
TTL indexes.