SQL operators compare or calculate values; precedence decides how a compound expression is grouped when parentheses do not specify the grouping.
A condition can be syntactically valid and still select the wrong people. The most common cause is an AND mixed with an OR whose intended grouping was never written down. Parentheses make the rule visible to both the database and the next reader.
This reference adds detail to the main course. You can read it independently: the small database below supplies every table and row used in the examples. Start with the question each query answers, then compare the returned values with the data rather than memorising a line of syntax.
Set up the practice database
Run this setup once in a new practice database, before the examples. It uses four customers and six sales. Ana has two sales, Ben has one, Cara has two, and Dev has none.
Sale 106 has no customer link; sale 104 has an unknown amount. These deliberate test cases expose missing information and unmatched relationships.
CREATE TABLE customers (
id INTEGER PRIMARY KEY,
name VARCHAR(40) NOT NULL,
city VARCHAR(40),
manager_id INTEGER
);
CREATE TABLE sales (
id INTEGER PRIMARY KEY,
customer_id INTEGER,
amount DECIMAL(10,2),
status VARCHAR(20) NOT NULL,
created_on DATE NOT NULL
);
INSERT INTO customers (id,name,city,manager_id) VALUES
(1,'Ana','Leeds',NULL),(2,'Ben','Leeds',1),
(3,'Cara','Porto',1),(4,'Dev',NULL,2);
INSERT INTO sales (id,customer_id,amount,status,created_on) VALUES
(101,1,10,'paid','2026-01-01'),
(102,1,30,'pending','2026-01-02'),
(103,2,20,'paid','2026-01-02'),
(104,3,NULL,'pending','2026-02-01'),
(105,3,20,'paid','2026-02-02'),
(106,NULL,5,'paid','2026-02-03');An amount of zero would be a known value. The NULL amount here means the value is unknown. A customer with no matching sale differs from a sale whose customer_id is NULL.
The primary keys identify individual records even when amounts or cities repeat. Dates use year-month-day format. The examples specify sorting whenever order matters; insertion order alone does not guarantee display order.
How SQL operators and precedence works
Comparison operators include =, <>, <, <=, > and >=. They produce a condition such as amount >= 20. Arithmetic operators include addition, subtraction, multiplication and division. Logical operators connect conditions: AND requires both conditions to be true, OR accepts either condition, and NOT negates a condition. These families do different jobs. An arithmetic expression can calculate a value that a comparison tests, and several comparisons can then form a logical rule.
AND binds more tightly than OR in the four databases discussed here. Therefore A OR B AND C means A OR (B AND C), rather than (A OR B) AND C. If a report needs paid sales worth at least twenty, or any pending sale, write (status = 'paid' AND amount >= 20) OR status = 'pending'. Read each parenthesised group aloud. The group should describe one clear business requirement, such as a qualifying paid sale.
Arithmetic order and unknown values
Arithmetic multiplication and division normally bind more tightly than addition and subtraction. For example, 10 + 2 * 3 produces 16, while (10 + 2) * 3 produces 36. Division is particularly sensitive to operand types: dividing two integers can truncate the fraction in some systems. Use an appropriate decimal operand when the fraction matters. Do not assume a mathematical-looking expression has the same type rules as a spreadsheet cell.
NULL introduces unknown truth values. amount >= 20 is unknown for sale 104 because its amount is missing. WHERE keeps only true conditions; it discards false and unknown conditions. An OR can still become true when its other side is true, so a pending sale with an unknown amount can pass a condition that explicitly accepts pending status. Logical grouping does not promise evaluation order or safe short-circuiting. Avoid relying on a preceding condition to protect an invalid calculation; use a suitable CASE expression or NULLIF for that purpose.
MySQL, PostgreSQL, SQL Server and SQLite
The AND-before-OR rule and the comparison <> are portable. String concatenation, bitwise operators, integer division and boolean value types differ. PostgreSQL has a boolean type; SQLite commonly represents truth with integers. Use decimal operands for portable ratio intent and check the resulting numeric type in your chosen engine.
Check the engine-specific syntax and version requirements in PostgreSQL operator precedence.
Practice task and worked solution
Return sales that are paid and whose amount is either ten or twenty. Group the amount alternatives so a pending sale of twenty would not be included.
Try the task before reading its worked solution. The supplied rows make the expected answer checkable by hand.
SELECT id FROM sales
WHERE status = 'paid'
AND (amount = 10 OR amount = 20)
ORDER BY id;id
101
103
105The status comparison applies to the entire parenthesised amount rule. Sale 101 matches ten, while 103 and 105 match twenty. Sale 106 is paid but worth five. Sale 102 is pending, so it cannot enter through either amount branch.
Compare (status='paid' OR status='pending') AND amount>=20 with status='paid' OR (status='pending' AND amount>=20). Sale 101 should enter only the second result, because it is paid but worth ten. Sale 104 remains excluded from these two versions because its unknown amount cannot satisfy the threshold. Explain that difference before experimenting with additional conditions.
SQL Operators and Precedence: AND, OR and Parentheses Syntax
SQL operators and precedence
SELECT id FROM sales
WHERE (status = 'paid' AND amount >= 20)
OR status = 'pending'
ORDER BY id;SQL Operators and Precedence: AND, OR and Parentheses Summary
- Comparison operators such as
=,<>and>=produce conditions;AND,ORandNOTcombine them. ANDbinds more tightly thanOR, soA OR B AND CmeansA OR (B AND C).- Multiplication and division happen before addition and subtraction unless parentheses say otherwise.
- A comparison with
NULLis unknown, andWHEREkeeps only rows whose whole condition is true. - Write parentheses around every mixed
AND/ORrule so its grouping matches the business requirement.
SQL Operators and Precedence: AND, OR and Parentheses Examples
Each example shows the code, the output it produces and what each part does.
Paid sales of 20 or more, or any pending sale
Sales 103 and 105 qualify as paid sales of twenty. Sales 102 and 104 qualify through pending status. Sale 104 passes even though its amount comparison is unknown, because its pending condition is true.
SELECT id FROM sales
WHERE (status = 'paid' AND amount >= 20)
OR status = 'pending'
ORDER BY id;id
102
103
104
105Common SQL Operators and Precedence: AND, OR and Parentheses Mistakes
Mixing AND and OR without parentheses
WHERE status = 'paid' OR status = 'pending' AND amount >= 20 applies the amount condition only to pending sales. If both statuses should need a known amount of at least twenty, group the status alternatives before AND. Merely moving the words onto separate lines does not change precedence.
SQL Operators and Precedence: AND, OR and Parentheses in Real Projects
Discount and eligibility rules
Discount rules often combine a customer category, a minimum purchase and an exception. Translate each part into a separate parenthesised condition before combining them. Check at least one row that qualifies through each branch and one that fails every branch, including a row with missing input.
Review eligibility rules as a truth table before embedding them in a report. A paid low-value sale, a paid high-value sale and a pending sale exercise different branches. If a rule includes an exception, write parentheses that visibly limit that exception to its intended population rather than letting OR admit unrelated records.
SQL Operators and Precedence: AND, OR and Parentheses FAQ
Should I memorise every precedence level?
No. Learn the common arithmetic and logical rules, especially that AND comes before OR, then use parentheses whenever a combination could be misread. Parentheses cost nothing and make the intended grouping obvious to the next reader as well as the database.
Does NOT turn NULL into true?
No. NOT applied to an unknown result is still unknown, so WHERE NOT (amount >= 20) still rejects sale 104, whose amount is NULL. To include missing values, say so explicitly: WHERE amount < 20 OR amount IS NULL.
Does AND guarantee the first condition runs first?
No. The optimiser can reorder evaluation, so WHERE quantity <> 0 AND total / quantity > 5 may still try the division. Express unsafe calculations in a form that remains valid for every row, such as total / NULLIF(quantity, 0) > 5.
What is the difference between <> and !=?
They mean the same thing: not equal. <> is the SQL standard operator, and != is accepted by MySQL, PostgreSQL, SQLite and SQL Server as well. Pick one style for a project and use it consistently.
Why does 10 + 2 * 3 give 16 in SQL?
Multiplication binds more tightly than addition, exactly as in arithmetic, so the database calculates 2 * 3 first and then adds 10. Write (10 + 2) * 3 to get 36. The same rule applies to calculated columns such as price + shipping * quantity.
SQL Operators and Precedence: AND, OR and Parentheses Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
Which sale ids pass (paid AND amount>=20) OR pending?
SQL Operators and Precedence: AND, OR and Parentheses Quiz
2 questions to check what you learned.
Which binds more tightly without parentheses?
- AND binds more tightly than OR
- OR binds more tightly than AND
- AND and OR are always grouped strictly left to right
What happens to an unknown condition in WHERE?
- It is accepted as true because no false value is known
- The row is excluded unless the full condition becomes true
- It always rejects the row even when another OR branch is true