SQL JOINチートシート

全開発ツール

無料

検索・印刷可能なSQL結合リファレンス。inner、left、right、full、anti、semi join、self join、ON対WHERE、LATERALを網羅。無料。

Basic join types

SELECT * FROM a INNER JOIN b ON a.id = b.a_id;

Only rows with a match in BOTH tables

SELECT * FROM a LEFT JOIN b ON a.id = b.a_id;

All left rows, NULLs where no match

SELECT * FROM a RIGHT JOIN b ON a.id = b.a_id;

All right rows, NULLs where no match

SELECT * FROM a FULL OUTER JOIN b ON a.id = b.a_id;

All rows from both, NULLs if unmatched

JOIN = INNER JOIN

Plain JOIN defaults to INNER

LEFT OUTER JOIN = LEFT JOIN

The OUTER keyword is optional

LEFT JOIN ... UNION ... RIGHT JOIN ...

Emulate FULL JOIN in MySQL (none native)

ON a.id = b.a_id AND a.type = b.type

Compound (multi-column) join condition

ON a.qty BETWEEN p.min_qty AND p.max_qty

Non-equi join: match on a range

Anti-joins (no match)

LEFT JOIN b ON a.id = b.a_id WHERE b.a_id IS NULL

Left rows with NO match on the right

WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id)

Anti-join; safe with NULLs

WHERE a.id NOT IN (SELECT a_id FROM b)

One NULL in the list = empty result!

WHERE a.id NOT IN (SELECT a_id FROM b WHERE a_id IS NOT NULL)

NOT IN made NULL-safe

RIGHT JOIN a ... WHERE a.id IS NULL

Right rows with no match on the left

SELECT id FROM a EXCEPT SELECT a_id FROM b;

Set difference (Postgres, MySQL 8.0.31+)

users without orders = LEFT JOIN + IS NULL

The classic anti-join use case

Prefer NOT EXISTS over NOT IN

Same plan, none of the NULL traps

Semi-joins (has a match)

WHERE EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id)

Left rows having a match; never duplicates

WHERE a.id IN (SELECT a_id FROM b)

Same intent; fine for short value lists

JOIN b ... GROUP BY a.id

JOIN duplicates 1-to-many; dedupe needed

SELECT DISTINCT a.* FROM a JOIN b ON ...

Semi-join via JOIN; EXISTS is cleaner

EXISTS stops at the first match

Often faster than joining everything

EXISTS (SELECT 1 ...) vs (SELECT * ...)

Selected columns are ignored; 1 is idiomatic

IN: uncorrelated / EXISTS: correlated

Optimizers usually rewrite them the same

users WITH orders = EXISTS subquery

The classic semi-join use case

Self joins

FROM emp e JOIN emp m ON e.manager_id = m.id

Each employee paired with their manager

FROM emp e LEFT JOIN emp m ON e.manager_id = m.id

Keeps top-level rows (manager is NULL)

SELECT e.name, m.name AS manager FROM ...

Aliases are REQUIRED to tell copies apart

ON a.id < b.id

Unique pairs: no self-match, no mirrors

ON a.id <> b.id

All ordered pairs except self-matches

ON b.day = a.day + INTERVAL 1 DAY

Adjacent rows (gaps and islands)

ON a.city = b.city AND a.id <> b.id

Other rows sharing the same value

WITH RECURSIVE tree AS (... UNION ALL ...)

Whole hierarchy: recursive CTE, not a join

Cross & multi-table joins

SELECT * FROM sizes CROSS JOIN colors;

Every combination: m x n rows, no ON

FROM sizes, colors

Implicit cross join; avoid this syntax

FROM users u JOIN orders o ON ... JOIN items i ON ...

Chain joins; each needs its own ON

JOIN dates d CROSS JOIN users u LEFT JOIN ...

Calendar x users grid, then fill data

u LEFT JOIN o ON ... LEFT JOIN i ON i.o_id = o.id

Keep LEFT down the chain to keep all users

u LEFT JOIN o ... INNER JOIN i ON i.o_id = o.id

INNER after LEFT drops the NULL rows!

FROM a JOIN (b LEFT JOIN c ON ...) ON ...

Parentheses control join grouping

Written order is logical, not execution order

The optimizer reorders inner joins freely

ON vs WHERE (the gotcha)

LEFT JOIN b ON a.id = b.a_id AND b.status = 1

Filters RIGHT side; all left rows kept

LEFT JOIN b ON a.id = b.a_id WHERE b.status = 1

NULL fails the test: LEFT becomes INNER!

WHERE b.a_id IS NULL OR b.status = 1

Keep unmatched rows despite a WHERE filter

LEFT JOIN b ON ... AND a.type = 'x'

Left-side filter in ON does NOT drop rows

WHERE a.type = 'x'

Filter the LEFT table in WHERE instead

INNER JOIN: ON and WHERE are equivalent

The trap only exists for outer joins

COALESCE(b.total, 0)

Replace outer-join NULLs with a default

COUNT(b.id) vs COUNT(*)

COUNT(col) skips NULLs: 0 for no match

USING, NATURAL & set ops

JOIN b USING (user_id)

Equi-join on a same-named column

USING outputs ONE shared column

ON keeps both a.user_id and b.user_id

NATURAL JOIN b

Auto-joins ALL same-named columns; fragile

Avoid NATURAL JOIN in production

A new column silently changes the join

SELECT ... UNION SELECT ...

Stack rows vertically, duplicates removed

UNION ALL

Keep duplicates; much faster than UNION

JOIN adds columns, UNION adds rows

Widen vs lengthen the result set

INTERSECT

Rows present in both result sets

UNION needs same column count and types

Names come from the first SELECT

LATERAL & performance

CROSS JOIN LATERAL (SELECT ... WHERE b.a_id = a.id LIMIT 3) t

Per-row subquery: top-N per group

LEFT JOIN LATERAL (...) t ON TRUE

Keep left rows whose subquery is empty

CROSS APPLY / OUTER APPLY

SQL Server spelling of LATERAL joins

LATERAL sees columns of preceding tables

A plain subquery in FROM cannot

CREATE INDEX idx ON orders (user_id);

Index the FK side of every frequent join

EXPLAIN SELECT ...;

Check join order, type, and index usage

Filter early: join the smallest set first

Less rows carried through each join

ON DATE(a.created_at) = b.day

Function on a column kills index use

Join on same-type, same-collation columns

Implicit casts also disable indexes

「:q」に一致する項目はありません。

SQL JOINチートシートについて

このSQL結合チートシートは、1つのことを徹底的に扱います。テーブルを組み合わせるあらゆる方法の解説です。8つのセクションで、基本的な結合の種類、一致しない行のためのアンチ結合、一致する行のためのセミ結合、self join、クロス結合と多テーブル結合、古典的なONとWHEREの落とし穴、USING、NATURAL、集合演算、そしてパフォーマンスに関する注意点付きのLATERAL結合をカバーしています。

結合はSQLの結果が静かに間違う典型的な場所です。WHERE句でフィルタされたLEFT JOINは知らぬ間にINNER JOINになり、NULLを含むNOT INは何も返しません。こうした落とし穴には、代わりに使うべき正しいパターンとともに、それぞれ独自の行が用意されています。

このグループの他のチートシートと同様、無料でクライアント側で動作します。検索ボックスで行をリアルタイムに絞り込み、追従する目次でセクション間を移動し、任意の文をワンクリックでコピーし、デスクでの参照用にページを印刷できます。

SQL JOINチートシートの使い方

シートを開き、基本的な結合の種類からLATERAL・パフォーマンスまでの各セクションを確認します。
LEFT JOIN、EXISTS、NOT INなどのキーワードを検索して、すべての行をリアルタイムに絞り込みます。
行数が少なすぎるLEFT JOINをデバッグする前に、ONとWHEREのセクションを読んでください。
文またはそのコピーアイコンをクリックして、SQLをクリップボードにコピーします。
印刷機能を使って、結合に関するリファレンス全体の紙のコピーを作成します。

よくある質問

inner、left、right、full outer joinに加え、アンチ結合、セミ結合、self join、クロス結合、多テーブル結合、USINGとNATURAL結合、UNION系の集合演算、LATERAL結合です。

ON内の条件は、外部結合が一致しない行を保持する前に結合対象のテーブルをフィルタします。同じ条件をWHEREに書くと、結合の後に実行されてNULL行が破棄され、LEFT JOINがINNER JOINに変わってしまいます。このシートにはまさにその点を扱ったセクションがあります。

アンチ結合のセクションでは、LEFT JOIN … WHERE right.id IS NULLとNOT EXISTSのパターンを示し、サブクエリがNULLを返しうる場合になぜNOT INが誤動作するかを説明しています。

はい。この構文は標準SQLであり、MySQL、PostgreSQL、SQL Server、SQLiteで動作します。エンジン固有の注意点が少数ある場合は、その行自体に記載されています。

はい、完全無料で、ログイン不要でブラウザ内で動作します。

SQL JOINチートシート

Basic join types

Anti-joins (no match)

Semi-joins (has a match)

Self joins

Cross & multi-table joins

ON vs WHERE (the gotcha)

USING, NATURAL & set ops

LATERAL & performance

SQL JOINチートシートについて

SQL JOINチートシートの使い方

よくある質問

このシートはどの結合の種類をカバーしていますか？

LEFT JOINにおけるONとWHEREの違いは何ですか？

一致しない行を見つけるにはどうすればよいですか？

MySQLやPostgreSQLにも当てはまりますか？

SQL結合のリファレンスは無料ですか？

関連ツール

人気の検索

このツールを埋め込む