One condition filters data; logical operators let you combine several into exactly the question you want to ask. AND, OR, and NOT glue conditions together inside a WHERE clause — “shipped and over $50,” “New York or London,” “not out of stock.” Get their precedence right and complex filters become easy to read; get it wrong and your query silently returns the wrong rows.
Every example below runs live in your browser against a small sample database. Edit it, press Run, and see the logic play out.
AND — every condition must be true
Sample tables you can query
AND — narrow the results
AND returns a row only when all its conditions are true. Each AND you add makes the result set smaller (or the same), never bigger — you’re stacking requirements:
SELECT product, status, amount
FROM orders
WHERE status = 'shipped' AND amount > 40;A row survives only if it is both shipped and over $40. Add a third AND and it must clear that bar too.
OR — widen the results
OR returns a row when at least one condition is true. Each OR makes the result set bigger (or the same) — you’re offering more ways to qualify:
SELECT *
FROM products
WHERE category = 'Electronics' OR category = 'Home';When you find yourself writing column = x OR column = y OR column = z against the same column, reach for the IN operator instead — category IN ('Electronics', 'Home') says the same thing, and is far easier to read and change.
OR — any condition qualifies
Sample tables you can query
NOT — exclude what matches
NOT flips a condition: it keeps the rows that don’t match. NOT price > 100 keeps everything priced 100 or less.
SELECT name, price
FROM products
WHERE NOT price > 50;NOT also fronts other operators — NOT IN (...), NOT LIKE '...', NOT BETWEEN ... AND .... Just watch out around NULL: because a comparison with NULL is UNKNOWN, negating it stays UNKNOWN (not true), so NOT-based filters silently drop rows with missing values. (The classic version of this trap lives in the IN operator guide.)
NOT — negate a condition
Sample tables you can query
Precedence: the parentheses trap
When you mix AND and OR in one clause, they are not evaluated left to right. NOT binds tightest, then AND, then OR. So this:
WHERE status = 'shipped' OR status = 'pending' AND amount > 40actually means status = 'shipped' OR (status = 'pending' AND amount > 40) — every shipped order, plus pending orders over $40. Almost certainly not what you intended. Parentheses make your meaning explicit and override precedence:
WHERE (status = 'shipped' OR status = 'pending') AND amount > 40Now it’s “either status, and over $40.” Run both and watch the row count change — same words, different answer:
AND before OR — parentheses decide
Sample tables you can query
The rule of thumb: whenever a single WHERE clause contains both AND and OR, add parentheses. Even when precedence happens to do what you want, the parentheses tell the next reader you meant it.
Practice
Return customers who are either in the UK OR in the Enterprise segment. Select name, country, and segment.
Sample tables you can query
Return orders that are shipped OR delivered, AND cost more than $30. Select product, status, and amount. (Mind the precedence!)
Sample tables you can query
Frequently asked questions
What are the logical operators in SQL? AND, OR, and NOT. AND requires all conditions to be true, OR requires at least one, and NOT negates a condition. They combine filters in the WHERE clause.
How do I use multiple conditions in a WHERE clause? Join them with AND or OR. When you mix the two, wrap OR groups in parentheses because AND is evaluated before OR.
What is the order of precedence for AND, OR, and NOT? NOT first, then AND, then OR. Parentheses override this, and using them whenever you mix operators is the safest habit.
When should I use IN instead of a chain of ORs? When every OR compares the same column to a value — x = 'a' OR x = 'b' OR x = 'c' becomes x IN ('a','b','c'), which is shorter and clearer.
From conditions to pipelines
Logical operators are how you express intent to a database one query at a time. When that logic needs to run continuously across many sources, ET1 turns it into a visual Filter node on a canvas — combine conditions with the same AND/OR logic, pointed at a CSV, a Postgres table, or an API, with a live preview of the rows passing through.
Keep building: filter one column against a list with the IN operator, match ranges with BETWEEN, or match text patterns with LIKE. New to the clause itself? Start with the WHERE clause guide.