🧭Keywords summary
Textual vs logical order
A compact map of the most common clauses anchors how SQL is written versus how it is evaluated. Logical processing order differs from textual order, understanding that resolves alias and aggregate confusion. Parsers build trees and optimizers rewrite, but semantics follow the standard logical model first.
Onboarding docs should show textual and logical order side by side at least once; quiz early on NULL with WHERE.
📋By area
Vendor extensions belong in a labeled appendix.
| Area | Keywords |
|---|---|
| Query | SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, OFFSET, FETCH |
| Joins | INNER, LEFT, RIGHT, FULL, CROSS, JOIN, ON, USING |
| Sets | UNION, UNION ALL, INTERSECT, EXCEPT |
| Change data | INSERT, UPDATE, DELETE, MERGE |
| Define objects | CREATE, ALTER, DROP, TABLE, INDEX, VIEW |
| Transactions | BEGIN, COMMIT, ROLLBACK, SAVEPOINT |
Teaching gaps
- Teaching textual order only, learners fail on HAVING vs WHERE.
- Mixing vendor extensions without labeling them.
- Assuming DISTINCT applies before WINDOW without checking.
Solid habits
- Memorize logical order as a checklist when debugging.
- Relate keywords to relational algebra names.
- Cross-link to vendor quirks explicitly in internal guides.
Windows
Window functions evaluate after grouping and aggregation, if a keyword feels “late” in the pipeline, it probably is.
TL;DR
SQL keywords are reserved language tokens (SELECT, FROM, WHERE, JOIN, GROUP BY, WINDOW, …). Engines extend the list with dialect-specific words, quote identifiers when names collide. Reading order of operations beats memorizing every synonym: know where grouping happens vs where windows run.