MongoDB
Revisa operadores de comparación, lógicos, existencia, tipos y expresiones para construir filtros precisos y compatibles con índices en MongoDB.
Un filtro de MongoDB es un documento BSON que describe qué condiciones debe cumplir un documento. Los operadores permiten expresar igualdad, comparación, lógica, existencia, tipos, arrays y expresiones.
{
businessId: ObjectId('...'),
status: { $in: ['pending', 'confirmed'] },
createdAt: { $gte: start, $lt: end }
}La sintaxis parece sencilla, pero su semántica depende de tipos BSON, null, campos ausentes, arrays, collation e índices.
Requisito:
Mostrar órdenes confirmadas o pendientes de un negocio creadas durante julio.
const filter = {
businessId,
status: { $in: ['pending', 'confirmed'] },
createdAt: {
$gte: new Date('2026-07-01T00:00:00Z'),
$lt: new Date('2026-08-01T00:00:00Z')
}
};El rango utiliza inicio inclusivo y final exclusivo. Esta convención evita problemas con milisegundos al construir periodos consecutivos.
Forma abreviada:
{ status: 'pending' }Forma explícita:
{ status: { $eq: 'pending' } }La comparación es sensible al tipo. Esto no coincide con un ObjectId:
{ businessId: '66a2...' }si el campo almacena:
{ businessId: ObjectId('66a2...') }Operadores:
$gt: mayor que;$gte: mayor o igual;$lt: menor que;$lte: menor o igual;$ne: diferente.Ejemplo:
{
stock: { $gte: 1 },
price: { $lt: Decimal128('50000.00') }
}Mantén tipos numéricos consistentes. Mezclar strings, double y Decimal128 dificulta interpretar resultados y rangos.
{ status: { $in: ['pending', 'confirmed'] } }$in funciona bien con listas controladas y valores indexables. Una lista enorme aumenta tamaño del comando y trabajo del planner. Si la lista proviene de input, limita cantidad y valida cada valor.
$nin y $ne suelen ser menos selectivos porque pueden coincidir con gran parte de la colección, incluyendo consideraciones sobre campos missing.
{
businessId,
status: 'pending'
}Ambas condiciones deben cumplirse.
Útil cuando necesitas combinar expresiones repetidas sobre la misma clave o construir dinámicamente:
{
$and: [
{ stock: { $gte: 1 } },
{ stock: { $lte: 100 } }
]
}A menudo puede simplificarse:
{ stock: { $gte: 1, $lte: 100 } }{
$or: [
{ status: 'pending' },
{ priority: 'urgent' }
]
}Cada rama debe evaluarse con índices. Un $or con una rama no indexable puede elevar el coste completo.
Coincide cuando ninguna expresión se cumple. Su semántica con campos ausentes puede sorprender; prueba casos reales.
Niega una condición sobre un campo:
{ price: { $not: { $gt: 100 } } }No es un operador lógico general equivalente a envolver cualquier documento arbitrario.
{ confirmedAt: { $exists: true } }Comprueba presencia del campo, no que tenga un valor no null.
{ total: { $type: 'decimal' } }Es útil para auditorías y migraciones. No debería ser necesario en cada query normal si el schema está gobernado.
Esta consulta:
{ discount: null }puede coincidir con documentos donde discount es null y documentos donde el campo no existe.
Para exigir presencia:
{
discount: null,
discount: { $exists: true }
}No puedes repetir la misma clave en un objeto JavaScript porque la segunda sobrescribe la primera. Debes combinar operadores:
{
discount: {
$eq: null,
$exists: true
}
}Para distinguir con precisión durante una auditoría puede utilizarse $type o $expr.
{
'customer.id': customerId,
'deliveryAddress.city': 'Bogotá'
}Dot notation consulta subcampos. No crea una relación ni otra collection.
La igualdad contra un documento completo depende de forma y orden de campos, por lo que suele ser más robusto consultar rutas específicas.
Una igualdad simple sobre un campo array puede coincidir si algún elemento tiene ese valor:
{ tags: 'coffee' }Para condiciones sobre el mismo elemento de un array de documentos utiliza $elemMatch:
{
items: {
$elemMatch: {
productId,
quantity: { $gte: 2 }
}
}
}Sin $elemMatch, condiciones separadas pueden cumplirse en elementos distintos:
{
'items.productId': productA,
'items.quantity': { $gte: 2 }
}Eso no garantiza que el item de productA tenga quantity mayor o igual a 2.
{ tags: { $all: ['coffee', 'organic'] } }Exige que el array contenga todos los valores.
{ items: { $size: 3 } }Exige tamaño exacto. $size no expresa rangos directamente y puede no aprovechar índices como esperas.
{ sku: /^CAF-/ }Una regex anclada por prefijo puede aprovechar ciertos índices según collation y opciones. Una regex no anclada:
{ name: /coffee/i }puede recorrer muchos valores y no reemplaza un motor de búsqueda.
Valida longitud y complejidad de patrones para evitar consumo excesivo. No construyas regex directamente desde input sin escaping o límites.
Collation cambia comparación y sort de strings:
db.customers.find({ name: 'jose' }).collation({
locale: 'es',
strength: 2
});Para utilizar un índice, la collation de la query debe ser compatible con la del índice. Lowercase manual no reproduce todas las reglas lingüísticas.
Permite utilizar expresiones de aggregation dentro del filtro:
{
$expr: {
$gt: ['$total', '$creditLimit']
}
}Es útil cuando la condición compara campos o requiere cálculos. Puede limitar el uso de índices según expresión y versión. No lo utilices cuando un filtro simple resuelve la query.
Este código es peligroso:
const filter = request.body;
await users.findOne(filter);Un atacante podría enviar:
{
"email": { "$ne": null }
}La mitigación es construir el filtro desde campos permitidos:
const filter: Record<string, unknown> = {
businessId: session.businessId
};
if (input.status) {
filter.status = input.status;
}Además:
TypeScript no valida datos recibidos en runtime.
Un filtro debe evaluarse como query shape.
{
businessId,
status: 'pending',
createdAt: { $gte: start, $lt: end }
}Índice candidato:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: 1
});El orden depende de igualdad, sort y rangos. No crees índices aislados para cada operador.
Devuelve ninguna coincidencia. Decide si representa un filtro válido o error de entrada.
Un rango puede excluir silenciosamente valores almacenados como string. Audita y migra.
$ne, $nin y null pueden incluirlo de formas no intuitivas. Prueba ejemplos.
Un constructor de query debe decidir si significa “sin filtro” o “sin resultados”; no generes semántica accidental.
Puede consumir CPU y causar latencia global.
Convierte límites de zona horaria a instantes UTC antes de consultar, conservando la zona del dominio cuando corresponda.
Permite injection y filtros fuera del scope.
Produce resultados vacíos o parciales.
Combina condiciones de elementos distintos.
Escala mal y no ofrece relevancia lingüística.
Puede examinar gran parte de la collection.
La sintaxis correcta no garantiza un plan eficiente.
explain('executionStats').Los filtros expresan semántica sobre BSON, no texto genérico. Tipo, existencia, arrays y collation cambian el resultado. La aplicación debe construir filtros seguros y el diseño debe comprobarlos con índices y datos reales.
$elemMatch?$ne puede ser poco selectivo?Documentos anidados y dot notation.