SQL JOIN Cheat Sheet: A Memory‑Friendly Guide

If you ever find yourself pausing mid‑query wondering “wait… WHERE goes before GROUP BY, right?”—this cheat sheet is for you.

This article gives you:

A simple mnemonic to remember JOIN structure
A clean mental model of how JOINs actually work
Copy‑paste examples you can recall under pressure

The One Mnemonic to Rule Them All

“Some Friendly Joins Only Work Great On Large Data”

Each word maps to the exact order of a SQL query:

Mnemonic Word	SQL Clause
Some	`SELECT`
Friendly	`FROM`
Joins	`JOIN`
Only	`ON`
Work	`WHERE`
Great	`GROUP BY`
On	`HAVING`
Large	`ORDER BY`
Data	`LIMIT / OFFSET`

If you remember the sentence, you remember the structure.

How to Remember JOIN Structure (The JOIN Sandwich)

Think of a JOIN as a sandwich:

FROM   base_table        ← bottom bread
JOIN   other_table       ← filling
ON     how_they_connect  ← sauce (the logic)

Nothing goes between JOIN and ON. Ever.

🧠 Rule: Tables first, relationship second.

The Canonical JOIN Structure (Cheat Version)

SELECT    columns
FROM      table_a
JOIN      table_b
ON        join_condition
WHERE     row_filters
GROUP BY  aggregates
HAVING    aggregate_filters
ORDER BY  sorting
LIMIT     pagination;

🔑 Golden rule: ON links tables, WHERE filters results.

The JOIN Spine (Ultra‑Simple Memory Hook)

If you forget everything else, remember this spine:

FROM → JOIN → ON

Everything else is optional decoration.

FROM answers: Where does the data start?
JOIN answers: What else do I want?
ON answers: How are they related?

If you can say those three things in English, you can write the JOIN.

JOIN Types — Remember Them by Shape

INNER JOIN — The Overlap

FROM orders o
INNER JOIN customers c
  ON o.customer_id = c.id

Only rows that match on both sides
Default JOIN if you just write JOIN

LEFT JOIN — All Left, Maybe Right

FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.id

Keeps all rows from the left table
Missing matches become NULL

🧠 Memory hook: LEFT keeps LEFT

RIGHT JOIN — Rare, but Real

FROM orders o
RIGHT JOIN customers c
  ON o.customer_id = c.id

Keeps all rows from the right table
Often rewritten as a LEFT JOIN for clarity

FULL OUTER JOIN — Everything, Match or Not

FROM a
FULL OUTER JOIN b
  ON a.id = b.id

All rows from both tables
Non‑matches padded with NULL

ON vs WHERE — The #1 JOIN Mistake

❌ This breaks LEFT JOIN logic:

LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'PAID'

✅ This preserves LEFT JOIN intent:

LEFT JOIN orders o
  ON o.customer_id = c.id
 AND o.status = 'PAID'

Rule of thumb:

ON controls matching

WHERE controls filtering after the match

Aggregates: GROUP BY Comes Before HAVING

Remember:

WHERE → filters rows
HAVING → filters groups

SELECT customer_id, COUNT(*) AS order_count
FROM orders
GROUP BY customer_id
HAVING COUNT(*) > 5;

Ultra‑Compact Pocket Cheat Sheet

Some Friendly Joins Only Work Great On Large Data
SELECT
FROM
JOIN
ON
WHERE
GROUP BY
HAVING
ORDER BY
LIMIT

Stick that sentence in your head and JOIN syntax stops being stressful.

Final Mental Model

Think of SQL execution like this:

Tables are combined (FROM + JOIN + ON)
Rows are filtered (WHERE)
Rows are grouped (GROUP BY)
Groups are filtered (HAVING)
Results are sorted and sliced (ORDER BY, LIMIT)

Once you see that flow, JOINs stop feeling magical and start feeling mechanical—in the best way.

If you want, I can also:

Turn this into a one‑page printable PDF
Create a JOIN decision flowchart
Write a “debugging JOINs” checklist