Logiska operatorer: $and, $or, $nor, $not

De flesta frågefilter innehåller villkor för flera fält, och alla bör inte kombineras med ett enkelt AND. Ibland vill ni ha dokument som uppfyller något av flera villkor, eller så vill ni utesluta dokument som matchar ett mönster. MongoDB:s logiska operatorer – $and, $or, $nor och $not – ger er full boolesk kontroll över filtervillkoren.

Genom att förstå när varje operator ska användas – och känna till genvägen med implicit AND – blir era frågor mer lättlästa och effektiva.

När du listar flera fältvillkor i ett och samma filterobjekt tillämpar MongoDB dem som ett implicit AND—alla villkor måste vara sanna för att ett dokument ska matcha. Detta är standardfallet och det vanligaste scenariot.

Implicit AND är både mer koncist och något effektivare än den explicita operatorn $and, eftersom MongoDB kan optimera villkor på fältnivå var för sig. Använd implicit AND när villkoren gäller olika fält och det inte finns någon tvetydighet.

Explicit $and krävs i en specifik situation: när du behöver tillämpa flera villkor på samma fält med olika operatorer och inte kan uttrycka dem i ett enda objekt (eftersom JavaScript-objekt inte kan ha dubbla nycklar).

Det vanligaste fallet är att kombinera två $or-villkor som båda refererar till fältet. Intervallvillkor på ett och samma fält ({ price: { $gte: 20, $lte: 100 } }) fungerar däremot bra i ett enda objekt—explicit $and behövs bara när uttrycken inte kan kombineras till ett enda fältvärde.

$or tar en array med filtervillkor och matchar dokument där minst ett av villkoren är sant. Det motsvarar SQL:s nyckelord OR i MongoDB.

Använd $or när du har alternativa vägar till samma resultat—till exempel när du vill hitta användare som antingen är administratörer eller har varit aktiva under de senaste 30 dagarna. En viktig prestandaaspekt är att MongoDB kan använda indexunion för att uppfylla frågan om varje villkor är indexerat separat—men ett enda sammansatt index som täcker alla villkor är ofta snabbare.

$nor matchar dokument där inget av de angivna villkoren är sant—det är komplementet till $or. Ett dokument måste inte uppfylla ALLA villkor i $nor-arrayen för att returneras.

$nor är mindre vanligt än $or, men är användbart för exkluderingslogik: ”hitta produkter som varken har utgått, är slut i lager eller tillhör den arkiverade kategorin”. Det matchar även dokument där de efterfrågade fälten saknas, eftersom saknade fält inte matchar något positivt villkor.

$not inverterar resultatet av ett uttryck med en operator på fältnivå. Till skillnad från $nor (som tar en array med fullständiga filtervillkor) omsluter $not en enskild operator eller ett reguljärt uttryck: { price: { $not: { $gt: 100 } } }.

$not matchar även dokument där fältet inte finns. Den är ofta överflödig tillsammans med $ne eller $nin, men är särskilt användbar för att negera reguljära uttryck: { name: { $not: /^admin/i } }—det finns ingen motsvarighet till $ne för reguljära uttryck.

Logiska operatorer kan nästlas för att uttrycka godtyckligt komplex boolesk logik. Tänk på det som att bygga ett logiskt träd: yttre $and-villkor kopplas samman på den översta nivån, medan $or-underuttryck uttrycker alternativ inom en gren.

Komplexa nästlade booleska frågor kan vara svåra att läsa—överväg att dela upp dem i namngivna JavaScript-variabler eller bygga filterobjektet programmatiskt utifrån användarinmatning, i stället för att nästla dem fem nivåer djupt i en enda objektliteral.

$or-frågor har ett särskilt beteende när det gäller indexanvändning. MongoDB utvärderar varje gren i $or separat och slår samman resultaten:

• Om varje gren kan använda ett index utför MongoDB en indexunion—effektivt
• Om någon gren inte kan använda ett index återgår MongoDB till en samlingsgenomsökning för den grenen—vilket kan vara långsamt

För bästa prestanda bör du se till att varje gren i $or har ett motsvarande index. När $or-villkor kan skrivas om som $in på samma fält ({ status: { $in: ['a','b'] } }) bör du göra det—$in är effektivare än en $or med två grenar på samma fält.

I aggregeringspipeline-steg som $match fungerar samma logiska operatorer exakt som i find(). Placera $match med dina logiska villkor så tidigt som möjligt i pipen för att minska antalet dokument som efterföljande steg behöver bearbeta.

I pipelineuttryckens operatorer (som $project eller $addFields) har logiska operatorer en något annorlunda syntax: { $and: [expr1, expr2] } som uttrycksoperatorer i stället för frågeoperatorer. Frågekontexter ($match) och uttryckskontexter ($project) använder samma operatörsnamn men olika syntax.

I riktiga applikationer byggs frågefilter ofta dynamiskt utifrån användarinmatning (sökformulär och API-frågeparametrar). Bygg filterobjektet programmatiskt och lägg bara till villkor när parametern har angetts—lägg inte till en $or: [] med tomma arrayer, eftersom det inte skulle matcha något.

Validera och sanera alla värden från användaren innan du tar med dem i en fråga. Skicka aldrig råa användarsträngar direkt till $regex utan att escapa dem—en angripare kan injicera ett katastrofalt långsamt reguljärt uttryck (en ReDoS-attack).

MongoDB utvärderar uttryck med logiska operatorer, men tillämpar INTE nödvändigtvis kortslutning på samma sätt som JavaScript. Frågeplaneraren kan ändra ordningen på villkoren för att effektivisera frågan—till exempel flytta ett villkor som använder ett index före ett som inte gör det, oavsett deras ordning i frågedokumentet.

En viktig följd är att i , om den första grenen orsakar en fullständig samlingsgenomsökning, kan hela frågan genomsöka samlingen även om den andra grenen använder ett effektivt index. Därför är det så viktigt för prestandan att se till att varje gren i är indexerad. Använd explain() för att kontrollera att körningsplanen motsvarar dina förväntningar.

I den här lektionen har du lärt dig att implicit AND är standard när du listar flera fält i ett filterobjekt—explicit $and behövs bara när du inte kan uttrycka villkoren som unika nycklar (till exempel två $or-block), att $or matchar vilket som helst av villkoren och använder indexunion när varje gren är indexerad, samt att $not inverterar en enskild operator och är särskilt användbar för att negera reguljära uttryck där $ne inte kan användas. Nästa steg är elementoperatorer som $exists och $type för hantering av valfria fält och fält med blandade typer.