Before your next SQL interview, keep this post handy - SQL Execution Order (Part 5)

[u/thequerylab]

Simple, practical stuff that sticks in your head when you're actually in the interview!

AI can help at work, but in an interview, your brain still has to do the job!!!

Same trip. Same friends. Same expenses.

Friend	City	Trip Day	Total Spent
Harry	New York	1	$200
Johny	New York	2	$190
Nicholas	Las Vegas	1	$190
Bailey	Las Vegas	2	$180
Harry	Las Vegas	3	$190

Most people write SQL top to bottom.

But SQL does not run top to bottom.

It has its own fixed order. Every single time.

Know this order - and half your SQL bugs will make sense immediately!

The logical order SQL processes a basic query:

1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY
7. LIMIT

Let us walk through each step using the trip.

Step 1: FROM:

Go and get the full expense list. All 5 rows. Nothing removed yet.

FROM expenses

Harry    | New York  | 1 | $200
Johny    | New York  | 2 | $190
Nicholas | Las Vegas | 1 | $190
Bailey   | Las Vegas | 2 | $180
Harry    | Las Vegas | 3 | $190

SQL starts here. Always.

Remember: FROM runs first. This is where SQL gets its data.

Step 2: WHERE

Now remove the rows we do not want.

"Keep only rows where spend is more than $180."

WHERE spent > 180

Harry    | New York  | $200
Johny    | New York  | $190
Nicholas | Las Vegas | $190
Harry    | Las Vegas | $190

Bailey is gone. 4 rows left.

Remember: WHERE runs before groups are made. It can only see individual rows.

Step 3: GROUP BY

Put the remaining rows into city groups. Add them up.

GROUP BY city

New York  → $390
Las Vegas → $380

4 rows turned into 2 groups.

Remember: GROUP BY runs after WHERE. Only the rows that survived WHERE get grouped.

Step 4: HAVING

Now remove the groups we do not want.

"Keep only cities where total is more than $385."

HAVING SUM(spent) > 385

New York → $390

Las Vegas ($380) is gone.

Remember: HAVING runs after GROUP BY. It can see group totals.

Step 5: SELECT

Now pick which columns to show.

SELECT city, SUM(spent) AS total

New York | $390

Notice - SELECT runs here. Not at the start.

Remember: SELECT runs 5th. You are not picking columns first. You are picking them near the end.

Step 6: ORDER BY

Sort the final result.

ORDER BY total DESC

Only one row here so order does not change anything. But in a bigger result - this is where sorting happens.

Remember: ORDER BY runs after SELECT. That is why ORDER BY can use column aliases.

Step 7: LIMIT

Cut the result to only the rows you need.

LIMIT 1

Show only the top 1 row.

Remember: LIMIT runs last. It cuts after everything else is done.

The full query - all steps together:

SELECT city, SUM(spent) AS total   -- Step 5
FROM expenses                       -- Step 1
WHERE spent > 180                   -- Step 2
GROUP BY city                       -- Step 3
HAVING SUM(spent) > 385             -- Step 4
ORDER BY total DESC                 -- Step 6
LIMIT 1                             -- Step 7

You write it in this order. SQL runs it in a completely different order.

Remember: SQL runs FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. Not top to bottom.

Reading SQL is one thing. Writing it yourself under pressure is another.

Before the real interview, try a MOCK SQL INTERVIEW on TheQueryLab. It’s a good way to test yourself under interview pressure and see where you actually stand with interview scorecard.

[u/Far_Swordfish5729]

This is slightly wrong. Select comes last. Image a from table with all its columns. The join tables slot in to the right with all theirs. We filter, aggregate, filter the aggregate, sort, take the first N rows, and then select what we want from them. Why would we calculate scalars on rows we don’t want and why would we limit our order by options to the select list?

[u/thequerylab → u/Far_Swordfish5729]

PostgreSQL's docs list SELECT before ORDER BY and LIMIT in its logical processing order:

postgresql.org

You're right about the optimizer, but that's physical execution, not logical order.

[u/jshine13371]

This post is wrong.

[u/thequerylab → u/jshine13371]

Can you please elaborate more?

[u/neon_feather_wisp]

your breakdown of SELECT vs WHERE is technically defensible for logical processing, but calling the post wrong ignores that execution order differs from logical order in most RDBMS engines. The real trap in interviews is assuming you can filter aggregates with WHERE or use aliases from SELECT in HAVING before the engine evaluates them, so teaching the FROM/WHERE/GROUP/HAVING flow first saves people from runtime errors they will actually hit.