If you’ve ever written SQL queries and wondered why sometimes things don’t behave as you expect —or why certain clauses must come before others— you’re not alone. SQL can feel a bit weird at first because the way we write queries isn't the way SQL executes them. Let’s unpack this.
syntactical Order vs Execution Order
When we write SQL, we often write it in this order:
SELECT column1, column2
FROM table
JOIN another_table ON ...
WHERE condition
GROUP BY column1
HAVING condition
ORDER BY column2
LIMIT n
This is the syntactical order. But it’s not the order in which the database actually processes the query.
Here’s the execution order in which SQL evaluates a query:
FROM and JOINWHEREGROUP BYHAVINGSELECTDISTINCTORDER BYLIMIT / OFFSET
Each step builds on the result of the previous. So for example, WHERE can only filter rows that exist after the FROM clause has brought them in, but before any grouping or aggregating happens.
Why Execution Order Matters?
Let’s look at a few examples that highlight why this execution order is critical.
Example 1: Alias Not Recognized in WHERE
SELECT salary * 1.1 AS increased_salary
FROM employees
WHERE increased_salary > 50000;
❌ This will throw an error!
Why? Because WHERE is evaluated before SELECT. So the alias increased_salary doesn't exist yet when WHERE runs.
✅ Fix:
SELECT salary * 1.1 AS increased_salary
FROM employees
WHERE salary * 1.1 > 50000;
Alternatively, use a subquery or CTE if you really want to reuse the alias:
WITH temp AS (
SELECT salary * 1.1 AS increased_salary
FROM employees
)
SELECT *
FROM temp
WHERE increased_salary > 50000;
Example 2: HAVING Before SELECT
SELECT department, COUNT(*) AS total
FROM employees
GROUP BY department;
HAVING total > 5
❌ Again, this doesn’t work! The total alias doesn't exist at the time the HAVING clause is executed.
✅ Instead, we need to re-write the aggregation:
SELECT department, COUNT(*) AS total
FROM employees
GROUP BY department
HAVING COUNT(*) > 5;
In practice, some modern DBMS (like MySQL and PostgreSQL) allow you to reference aliases from the SELECT clause inside the HAVING clause as a convenience, even though it's not part of the strict syntactical order.
So the above example will work in many databases. However, this is not guaranteed by the SQL standard and not supported by all DBMS (e.g., SQL Server might not allow it). So it’s better to be cautious.
Best Practices Based on Execution Order
To avoid common SQL pitfalls, keep these tips in mind:
1. Don’t reuse SELECT aliases in WHERE or GROUP BY.
Use the full expression or refactor using a subquery or CTE.
2. Use CTEs (WITH clauses) for readability and reuse.
They're evaluated like subqueries and can help avoid aliasing issues.
3. Remember, WHERE filters rows before aggregation.
Use HAVING to filter after aggregation.
4. Use aliases safely in ORDER BY (always) and HAVING (with caution).
While many DBMS allow alias use in HAVING, it’s not standard-compliant. For portability and clarity, prefer reusing the expression or using a subquery/CTE.
5. Think like the engine.
Understanding the execution order helps debug tricky issues and write cleaner, more efficient queries.
Final Thoughts
SQL might look like it reads top to bottom — but under the hood, it’s a well-orchestrated sequence of operations. Understanding the processing order helps you write smarter queries, avoid confusing errors, and better leverage the power of SQL.
What other SQL mysteries have tripped you up? Let’s chat in the comments 👇
SOCIAL SHARE CARD GENERATOR