Reviewed by Aditya Kumar · Last reviewed 2026-03-24
**Logical order**: (1) FROM/JOIN—sources; (2) WHERE—row filter; (3) GROUP BY—aggregation; (4) HAVING—aggregate filter; (5) SELECT—projection, expressions, aliases; (6) DISTINCT; (7) ORDER BY; (8) LIMIT/OFFSET. **Why it matters**: You can't reference SELECT aliases in WHERE (they...
Logical order: (1) FROM/JOIN—sources; (2) WHERE—row filter; (3) GROUP BY—aggregation; (4) HAVING—aggregate filter; (5) SELECT—projection, expressions, aliases; (6) DISTINCT; (7) ORDER BY; (8) LIMIT/OFFSET. Why it matters: You can't reference SELECT aliases in WHERE (they don't exist yet); HAVING runs after GROUP BY so you filter on aggregates. Optimizer reality: Plan may reorder (predicate pushdown, join reorder) but semantics preserve this order. Performance implication: Filter early in WHERE to reduce rows before expensive joins/aggregates; use HAVING only when necessary.
Red Flag: Using HAVING for non-aggregate conditions—wastes compute. Pro-Move: 'We moved department IN (...) from HAVING to WHERE, cutting rows before GROUP BY—query time dropped 70%.'
According to DataEngPrep.tech, this is one of the most frequently asked SQL interview questions, reported at 1 company. DataEngPrep.tech maintains an editor-reviewed database of 1,863 data engineering interview questions across 7 categories.