The 12 SQL cheat sheets that cover 95% of real query work
Most SQL cheat sheets are keyword dumps that answer nothing. These 12 free one-pagers are organized around the questions that actually block you at work: duplicate rows after a join, aliases that error, queries that ignore their index. Each one is a printable reference with real examples.
Search for a SQL cheat sheet and you get walls of keywords: every clause, every function, no hierarchy. That is a syntax dump, not a reference. Real query work fails in predictable places, a join that silently doubles revenue, an alias that errors in WHERE, an index the engine refuses to use, and a good cheat sheet is built around one of those failures. Here are the 12 free one-pagers that cover about 95% of the SQL you will write, grouped by the level where each problem shows up.
The 12 sheets at a glance:
- SQL JOINs
- WHERE vs HAVING
- SQL execution order
- The core SQL functions
- SQL dates
- NULL handling
- CTE vs subquery
- Window functions
- GROUP BY vs PARTITION BY
- JSON in SQL
- SQL indexing
- Slow query debugging
Why one-pagers beat the giant reference
A single mega-sheet with all of SQL on it optimizes for looking complete. A working reference optimizes for speed: you hit a wall, you scan one page, you get unblocked, you go back to work. That is why each of these sheets covers exactly one problem, states the trap in plain language, and shows the failing and working query next to each other. They are the same sheets D8A publishes daily as cheat sheets on social, collected here in the order you will actually need them.
Fundamentals: the four sheets that explain most errors
These four cover the mistakes that generate the majority of beginner and intermediate confusion. If you only bookmark one section, make it this one.
SQL JOINs
The 4 joins you actually use, plus the two traps that silently multiply rows and produce wrong numbers. Reach for it the moment a join returns more rows than the table you started with.
WHERE vs HAVING
Why WHERE AVG(salary) > 60000 errors every time: WHERE runs before groups exist. The one-word fix, and the performance trap of filtering in the wrong clause.
SQL execution order
You write queries top to bottom; the engine runs them in a different order. This one fact explains alias errors, WHERE vs HAVING, and half the confusing behavior in SQL.
SQL functions
The 25 functions that answer 80% of real queries, aggregates, strings, dates, NULLs, conditionals, each with a five-word gloss on one printable page.
Start with SQL JOINs explained and the SQL execution order: together they preempt most of what stumps people in their first year. Then keep WHERE vs HAVING and the core SQL functions within reach for daily writing.
Intermediate: where analyst work actually lives
Once joins and grouping feel automatic, day-to-day analytics runs on dates, NULLs, and window logic. These six sheets are the ones working analysts reach for weekly.
SQL dates
Truncate, extract, date math, the monthly report skeleton, and month-over-month growth with LAG. Every date pattern you keep googling, on one page.
NULL handling
Why WHERE email = NULL matches zero rows, ever. Three-valued logic, IS NULL, COALESCE, and the two NULL traps that quietly empty your results.
CTE vs subquery
What each is for, a four-question decision rule, the CTE plus ROW_NUMBER top-N interview pattern, and the NOT IN trap that returns zero rows.
Window functions
A value per row, computed over a group, without collapsing anything. The anatomy, the ranking trio, and the top-N pattern interviews love.
GROUP BY vs PARTITION BY
GROUP BY turns 200 rows into 3; PARTITION BY keeps all 200 and adds group context to each. The side-by-side queries and the rule of thumb that picks between them.
JSON in SQL
The Postgres jsonb operators decoded: reading keys, filtering, exploding arrays into rows, and the text trap hidden inside the double arrow.
The details live in SQL dates, NULL handling, CTE vs subquery, window functions, GROUP BY vs PARTITION BY, and querying JSON in SQL. If you are prepping interviews, the window functions and CTE sheets carry the two patterns SQL screens test most.
Debugging and performance: when correct is not enough
Eventually a correct query takes 40 seconds and someone asks you why. These two sheets are the playbook for that conversation.
SQL indexing
The sorted-copy mental model, why the engine ignores an index wrapped in a function, the sargable rewrite that wakes it up, and when an index actually hurts.
Slow query debugging
How to read the actual plan instead of the query text, the three query shapes that silently kill indexes, and what to do when indexes are not enough.
Read SQL indexing first for the mental model, then the slow query playbook for the step-by-step diagnosis. Together they turn "it's slow" from a shrug into a procedure.
How to actually use a cheat sheet
Collecting references feels like progress and changes nothing. The sheets earn their keep in exactly two modes, and both are active.
- 1
Use them as a working reference
Mid-task, a one-pager answers the specific question blocking you. That is lookup, and it is legitimate. What it is not is learning.
Questions to ask- Keep them open while you write real queries
- Scan for the trap, not the syntax
- Thirty seconds, then back to work
- 2
Drill them with recall practice
Recall is what makes a pattern survive an interview or a live incident. Reading a sheet five times builds recognition; reproducing it once from memory builds the skill.
Questions to ask- Read a sheet, close it
- Rewrite the core pattern from memory
- Check, note the gap, repeat tomorrow
- 3
Apply them in a real project
A cheat sheet proves you can look something up. A finished project proves you can use it. Only one of those gets you interviews.
Questions to ask- Messy data, real business question
- Joins, dates, windows in one analysis
- Published where a recruiter can open it
A cheat sheet you read is trivia. A cheat sheet you can rewrite from memory, then apply to messy data, is a skill.
That last step is the one that counts. SQL patterns only become hireable proof once they show up inside a finished analysis someone can open: a real dataset, a real question, a documented answer. If you want concrete places to apply these twelve sheets, start with our data analyst portfolio project ideas, or the broader list of data portfolio project ideas across roles. Every D8A path is built on exactly that principle: guided real projects where the joins, windows, and EXPLAIN plans stop being flashcards and become work you can defend.