SQL JOIN — 複雑な結合パターンとテーブル変化の応用

QUESTION 6

FULL OUTER JOIN — 双方向の欠損を許容して2つのデータセットを完全突合する

FULL OUTER JOINCOALESCEデータ突合双方向欠損

前提知識 ▼

LEFT JOIN は「左テーブルを全て残す」、RIGHT JOIN は「右テーブルを全て残す」のに対し、FULL OUTER JOIN は「どちらのテーブルの行も取りこぼさずに全て結果に残す」結合です。片方にしか存在しない行は、反対側が NULL で補完されます。

-- 結合タイプの比較（左: A={1,2,3}  右: B={1,3,4} の場合）
LEFT  JOIN → 1, 2, 3       (Bに無い2はB側がNULL)
RIGHT JOIN → 1, 3, 4       (Aに無い4はA側がNULL)
FULL  JOIN → 1, 2, 3, 4    (2はB側NULL、4はA側NULL)

COALESCE で両側の NULL を補完： FULL JOIN では双方にNULLが生じます。IDや名前など「どちら側にも存在し得る列」は COALESCE(lm.col, tm.col) と両側を書いてNULLを補完するのが定石です。

MySQL 非対応：MySQLはFULL OUTER JOINをサポートしていません。LEFT JOIN … UNION ALL … RIGHT JOIN WHERE A.id IS NULL で代替します。PostgreSQL・BigQuery・SQL Server等では利用可能です。

問題 ▼

ECサイトの先月（last_month）と今月（this_month）の商品別売上テーブルがあります。商品によって、先月のみ売れたもの・今月のみ売れたもの・両月売れたものが混在しています。

全商品を網羅して、先月の売上（last_amount）と今月の売上（this_amount）を横に並べてください。片方の月に存在しない商品は NULL となります。

使用テーブル

▸ last_month

product_id	product_name	amount
1	PC	500
2	マウス	120
3	キーボード	280

▸ this_month

product_id	product_name	amount
1	PC	630
3	キーボード	210
4	モニター	450

期待出力 ▼

product_id	product_name	last_amount	this_amount
1	PC	500	630
2	マウス	120	NULL
3	キーボード	280	210
4	モニター	NULL	450

模範解答コード ▼

SELECT
  COALESCE(lm.product_id,   tm.product_id)   AS product_id,
  COALESCE(lm.product_name, tm.product_name) AS product_name,
  lm.amount AS last_amount,
  tm.amount AS this_amount

FROM last_month AS lm
FULL OUTER JOIN this_month AS tm    -- どちらのテーブルにしかない行も全て残す
  ON lm.product_id = tm.product_id
ORDER BY
  product_id;

/*
  実行順序:
  1. FROM last_month AS lm       → 左テーブル
  2. FULL OUTER JOIN this_month  → product_id で照合
  3. SELECT COALESCE(...)        → lm・tm どちら側にもNULLが来得る列は COALESCE で補完
  4. ORDER BY product_id         → 昇順で出力
  */

解説（テーブル変化・ポイント） ▼

SELECT
  COALESCE(lm.product_id, tm.product_id) AS product_id,
  COALESCE(lm.product_name, tm.product_name) AS product_name,
  lm.amount AS last_amount,
  tm.amount AS this_amount
FROM last_month AS lm
FULL OUTER JOIN this_month AS tm
  ON lm.product_id = tm.product_id
ORDER BY
  product_id;

LEGEND ▼

データ取得・読込対象

① FROM ▼

FROM last_month AS lm先月の売上テーブル（3行）をベースとして読み込みます。product_id 1, 2, 3 が存在します。

1 / 3

product_id	product_name	amount
1	'PC'	500
2	'マウス'	120
3	'キーボード'	280

全 3行読込

学習ポイント

JOIN PATTERN

FULL OUTER JOIN（完全外部結合・両方向和）

どちら側の行も取りこぼさない完全突合
lm = last_month tm = this_month

使いどころは「データ突合・差異確認」：FULL OUTER JOIN が最も力を発揮するのは、2つのデータソース（例：DBの商品マスタ vs 外部CSVの商品リスト）を照合して「どちらかにしか存在しない差異」を洗い出す場面です。マッチした行・左のみの行・右のみの行を一度に俯瞰でき、データの整合性チェックに欠かせません。

COALESCE は「どちら側に値があるかわからない列」に使う：通常のLEFT JOINではNULLが来るのは右側だけですが、FULL JOINでは左右どちら側にもNULLが発生します。product_id や product_name などの「マスタ系の列」は COALESCE(lm.col, tm.col) と両側を記述するのを忘れずに。

アンチパターン

WHERE句でNULL行を消してしまう：WHERE lm.amount > 0 のような条件をWHEREに書くと、lm側がNULLの行（今月のみの商品）が全て除外されます。FULL JOINの後に片側の行を条件で絞りたい場合は WHERE lm.amount > 0 OR lm.amount IS NULL のようにNULL許容を明示します。

MySQL環境での直接使用：MySQLはFULL OUTER JOINをサポートしません。代替は SELECT … FROM A LEFT JOIN B … UNION ALL SELECT … FROM A RIGHT JOIN B … WHERE A.id IS NULL の組み合わせですが、可読性が大きく低下します。環境確認を忘れずに。

QUESTION 7

ANTI JOIN — LEFT JOIN + WHERE IS NULL で「存在しないこと」を条件にする

LEFT JOINANTI JOIN差集合NOT EXISTS

前提知識 ▼

「テーブルAにあるが、テーブルBにはない行」を取得する操作を ANTI JOIN（差集合）と呼びます。離脱ユーザー検出・未処理チケットの洗い出し・マスタに存在しないデータの特定など、実務で非常に頻出するパターンです。

実現方法は主に2つあります。

-- ① LEFT JOIN + WHERE IS NULL（本問で学ぶ手法）
SELECT a.* FROM A LEFT JOIN B ON a.id = b.id
WHERE b.id IS NULL;

-- ② NOT EXISTS（意図がより明確）
SELECT a.* FROM A
WHERE NOT EXISTS (SELECT 1 FROM B WHERE b.id = a.id);

NOT IN は使わない：WHERE a.id NOT IN (SELECT id FROM B) は、サブクエリ結果に NULL が1つでも含まれると全行が UNKNOWN になり、結果が空になります。ANTI JOINには LEFT JOIN か NOT EXISTS を使ってください。

問題 ▼

先月購入した顧客テーブル（last_buyers）と今月購入した顧客テーブル（this_buyers）があります。

先月は購入したが、今月は購入しなかった（離脱した）顧客の user_id と user_name を抽出してください。

使用テーブル

▸ last_buyers

user_id	user_name
1	田中
2	佐藤
3	鈴木
4	高橋

▸ this_buyers

user_id
1
3

期待出力 ▼

user_id	user_name
2	佐藤
4	高橋

模範解答コード ▼

SELECT
  l.user_id,
  l.user_name

FROM last_buyers AS l
LEFT JOIN this_buyers AS t  -- LEFT JOIN で先月の全顧客を残しつつ今月データと照合
  ON l.user_id = t.user_id
WHERE t.user_id IS NULL    -- 右側(this_buyers)がNULLの行 = 今月に存在しなかった顧客
ORDER BY l.user_id;

/*
  実行順序:
  1. FROM last_buyers AS l       → 先月の全顧客
  2. LEFT JOIN this_buyers AS t  → user_id で照合
  3. WHERE t.user_id IS NULL     → NULLになった行(=今月不在)だけを通過させる
  4. SELECT l.user_id, ...       → 離脱顧客の情報を射影して出力
  */

解説（テーブル変化・ポイント） ▼

SELECT
  l.user_id,
  l.user_name
FROM last_buyers AS l
LEFT JOIN this_buyers AS t
  ON l.user_id = t.user_id
WHERE t.user_id IS NULL;

LEGEND ▼

データ取得・読込対象

① FROM ▼

FROM last_buyers AS l先月の全顧客（4行）をベーステーブルとして読み込みます。

1 / 4

user_id	user_name
1	田中
2	佐藤
3	鈴木
4	高橋

全 4行読込

学習ポイント

JOIN PATTERN

ANTI JOIN（差集合・不在の検出）

左テーブルのうち、右テーブルに存在しない行だけを取得
l = last_buyers t = this_buyers

「存在しない」を条件にするには JOIN が必要：SQL の WHERE 句は「その行の値」しか評価できません。「別のテーブルにない」という条件は自テーブルだけでは判断できないため、LEFT JOIN や相関サブクエリを使って他テーブルの情報を参照する必要があります。

LEFT JOIN vs NOT EXISTS の使い分け：パフォーマンスはDBエンジンの最適化により同等になることが多いですが、意図の明確さでは NOT EXISTS が優れています。「このユーザーの注文が存在しないか」という意図は WHERE NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = u.user_id) の方が直感的に読めます。

アンチパターン

NOT IN + サブクエリは NULL に脆弱：サブクエリの結果に1行でも NULL が含まれると、NOT IN は全行に対して UNKNOWN を返し、結果が0行になります。エラーも警告も出ないサイレントバグで、発見が非常に困難です。ANTI JOINには必ず LEFT JOIN か NOT EXISTS を使ってください。

SELECT l.user_id, l.user_name
FROM last_buyers AS l
WHERE l.user_id NOT IN (
  SELECT user_id
  FROM this_buyers
);

LEGEND ▼

データ取得・読込対象

① サブクエリ結果（NULL混入） ▼

SELECT user_id FROM this_buyers ← NULLが1行混入したケースデータ品質問題などで this_buyers に NULL が混入しているケースを考えます。NOT IN はこの状況で致命的なバグを引き起こします。

1 / 2

user_id
1
3
NULL

NULLを含む 3行（現実に起こり得る）

実務コラム：ANTI JOINの実務活用

実務で最もよく使うANTI JOINのシーンは「未処理・未対応データの抽出」です。「問い合わせはあったが返答レコードがないチケット」「注文は入ったが発送テーブルに存在しない注文」など。LEFT JOIN + WHERE IS NULL はこれらの「漏れ・抜け」を素早く検出するための強力な定型構文として必ず習得しておきましょう。

QUESTION 8

多対多 (M:N) JOIN — 中間テーブルを2段階でたどってタグ検索を実装する

INNER JOIN多対多中間テーブルタグシステム

前提知識 ▼

「1つの記事には複数のタグが付く」「1つのタグは複数の記事に付く」というような多対多（M:N）の関係は、外部キーを2つ持つ中間テーブル（junction table）でモデリングされます。これはWebアプリのDB設計で最も頻出する構造の1つです。

-- 多対多の代表的なDB構造
articles      (article_id, title)       ← エンティティA
tags          (tag_id, tag_name)        ← エンティティB
article_tags  (article_id, tag_id)     ← 中間テーブル（橋渡し）

-- 取得パターン: articles → article_tags → tags と2段階でたどる
FROM articles AS a
INNER JOIN article_tags AS at ON a.article_id = at.article_id
INNER JOIN tags         AS t  ON at.tag_id    = t.tag_id

DISTINCT が必要な場面：記事に複数の対象タグがついている場合、同じ記事が複数行に展開されます。記事の一覧だけ取得したい場合は SELECT DISTINCT で重複を除去するのが定石です。

問題 ▼

記事テーブル（articles）、タグテーブル（tags）、および両者を紐付ける中間テーブル（article_tags）があります。

タグ名が 'React' のタグが付いた記事の article_id と title を取得してください。

使用テーブル

▸ articles

article_id	title
1	ReactでSPAを作る
2	SQL JOINを完全解説
3	VueとReactを比較する

▸ tags

tag_id	tag_name
1	React
2	SQL
3	Vue

▸ article_tags（中間テーブル）

article_id	tag_id
1	1
2	2
3	1
3	3

期待出力 ▼

article_id	title
1	ReactでSPAを作る
3	VueとReactを比較する

模範解答コード ▼

SELECT DISTINCT
  a.article_id,
  a.title

FROM articles AS a
INNER JOIN article_tags AS at      -- ① articles と中間テーブルを article_id で接続
  ON a.article_id = at.article_id
INNER JOIN tags AS t               -- ② 中間テーブルと tags を tag_id で接続（2段階目）
  ON at.tag_id = t.tag_id
WHERE t.tag_name = 'React'        -- ③ タグ名で絞り込む
ORDER BY a.article_id;

/*
  実行順序:
  1. FROM articles AS a             → 記事テーブル
  2. INNER JOIN article_tags AS at  → article_id で照合
  3. INNER JOIN tags AS t           → tag_id で照合し、タグ名を付加する
  4. WHERE t.tag_name = 'React'     → Reactタグが付いた行のみに絞る
  5. SELECT DISTINCT ...            → 重複除去して article_id, title を出力
  */

解説（テーブル変化・ポイント） ▼

SELECT DISTINCT
  a.article_id,
  a.title
FROM articles AS a
INNER JOIN article_tags AS at
  ON a.article_id = at.article_id
INNER JOIN tags AS t
  ON at.tag_id = t.tag_id
WHERE t.tag_name = 'React';

LEGEND ▼

データ取得・読込対象

① FROM ▼

FROM articles AS a記事テーブル（3行）をベースとして読み込みます。

1 / 5

article_id	title
1	'ReactでSPAを作る'
2	'SQL JOINを完全解説'
3	'VueとReactを比較する'

全 3行読込

学習ポイント

JOIN PATTERN

M:N 多対多 JOIN（中間テーブル経由）

articles ← article_tags → tags と2段階でたどる
中間テーブルが「橋渡し」の役割を担う

なぜ中間テーブルが必要か：記事に tag_id を直接持たせると「複数タグが付けられない」という制約が生じます。中間テーブルを設けることで、1記事に何個でもタグを付けられる柔軟な設計が実現します。M:N パターンは 記事×タグ、ユーザー×ロール、商品×カテゴリ など、実務のあらゆる場面に登場します。

「行が展開される」ことを意識する：中間テーブルとのJOINにより、複数のタグを持つ記事はタグの数だけ行が増えます。この「行の展開」を常に意識し、必要に応じて SELECT DISTINCT や GROUP BY で集約することが、正確な結果を得るための重要な視点です。

アンチパターン

DISTINCT の忘れ：記事3のように複数のタグを持つ記事は中間テーブルJOINで2行以上展開されます。article_id, title だけ取得したいのに DISTINCT を書き忘れると同じ記事が複数回出力されます。「中間テーブル経由のJOIN後は行が増える」と常に意識しましょう。

配列型カラムへの逃避：一部のDBでは tags を TEXT[] 配列型に詰め込む設計が見られますが、「Reactタグの全記事を検索」「タグの追加・削除・リネーム」などが後から困難になります。正規化された中間テーブルはスケーラビリティに直結します。

実務コラム：M:N設計と中間テーブル

M:N JOINは現代のWebアプリのほぼ全てに存在します。ECサイトの商品×カテゴリ、SNSのユーザー×フォロー（自己参照の中間テーブル）、権限管理のユーザー×ロールなど。ORMを使うと自動的に解決されますが、裏側では必ずこの2段階INNER JOINが発行されています。パフォーマンス問題が起きたときにSQLレベルで理解していることが重要です。

QUESTION 9

CTE + JOIN — WITH句で仮想テーブルを段階的に構築してコホート分析を実装する

CTE / WITHLEFT JOINコホート分析多段階集計

前提知識 ▼

複雑な集計SQLを一つのSELECT文に詰め込むと、ネストしたサブクエリが積み重なって可読性・保守性が著しく低下します。WITH 句（CTE: Common Table Expression）を使うと、集計を段階的な名前付き仮想テーブルに分解し、それをメインクエリでJOINして使うことができます。

-- CTEの基本構文
WITH cte_name AS (
  SELECT ...          -- ここに集計クエリを書く
  FROM   source_table
  GROUP BY ...
)
SELECT *
FROM   main_table
LEFT JOIN cte_name ON ...;  -- CTEをテーブルとしてJOINできる

ON句に日付計算を書く：LEFT JOINのON句には等価条件だけでなく fo.first_order_date <= u.register_date + INTERVAL '30 days' のような計算式も書けます。WHEREでなくON句に書くことで、LEFT JOINの左側の行を消さずに条件を適用できます。

問題 ▼

ユーザーの登録情報（users）と注文履歴（orders）テーブルがあります。ユーザーは複数回注文することがあります。

登録月（コホート月）ごとに、登録から30日以内に初回購入したユーザー数（converted_users）と全体の登録者数（total_users）を集計してください。

使用テーブル

▸ users

user_id	register_date
1	2024-04-01
2	2024-04-20
3	2024-05-05
4	2024-05-10

▸ orders

order_id	user_id	order_date
101	1	2024-04-10
102	1	2024-06-01
103	2	2024-07-01
104	3	2024-05-15

期待出力 ▼

cohort_month	total_users	converted_users
2024-04	2	1
2024-05	2	1

模範解答コード ▼

-- ① CTEで各ユーザーの「初回注文日」だけを集計する
WITH first_orders AS (
  SELECT
    user_id,
    MIN(order_date) AS first_order_date
  FROM orders
  GROUP BY user_id
)
SELECT
  TO_CHAR(u.register_date, 'YYYY-MM') AS cohort_month,
  COUNT(u.user_id)  AS total_users,
  COUNT(fo.user_id) AS converted_users                   -- fo.user_id が NULL でない行 = 30日以内に購入したユーザー

FROM users AS u
LEFT JOIN first_orders AS fo                                       -- ② CTEとJOINし、「30日以内」という時間条件もON句で指定する
  ON  u.user_id           = fo.user_id
  AND fo.first_order_date <= u.register_date + INTERVAL '30 days'
GROUP BY
  cohort_month
ORDER BY
  cohort_month;

/*
  実行順序:
  1. [CTE] FROM orders             → 注文テーブル
  2. [CTE] GROUP BY user_id        → MIN(order_date)で初回注文日を算出
  3. FROM users AS u               → ユーザーテーブル
  4. LEFT JOIN first_orders AS fo  → user_id と 30日以内条件で照合
  5. GROUP BY cohort_month         → 登録月ごとにグループ化して集計
  */

解説（テーブル変化・ポイント） ▼

WITH first_orders AS (
  SELECT
    user_id,
    MIN(order_date) AS first_order_date
  FROM orders
  GROUP BY user_id
)
SELECT
  DATE_TRUNC('month', u.register_date) AS cohort_month,
  COUNT(u.user_id) AS total_users,
  COUNT(fo.user_id) AS converted_users
FROM users AS u
LEFT JOIN first_orders AS fo
  ON u.user_id = fo.user_id
  AND fo.first_order_date <= u.register_date + INTERVAL '30 days'
GROUP BY
  cohort_month
ORDER BY
  cohort_month;

LEGEND ▼

データ取得・読込対象

① CTE FROM ▼

FROM orders ← CTE (first_orders) 内の処理CTEの中でまず orders テーブル（4行）を読み込みます。ユーザー1は2回注文していますが、MIN(order_date)で初回のみを取り出します。

1 / 6

order_id	user_id	order_date
101	1	'2024-04-10'
102	1	'2024-06-01'
103	2	'2024-07-01'
104	3	'2024-05-15'

orders 全 4行読込

学習ポイント

PATTERN

CTE + JOIN（段階的な集計結合）

WITH句で仮想テーブルを先に構築し、メインクエリでJOINする
CTE → LEFT JOIN + 条件 → GROUP BY → SELECT

CTE の本質は「可読性の向上」：CTEはパフォーマンスを劇的に改善する魔法ではなく、複雑なネストしたサブクエリを「段階的に名前をつけて整理する」道具です。同じ処理をサブクエリで書けますが、CTEを使うことでクエリが上から下へ読めるようになり、レビューやデバッグが格段に楽になります。

ON句とWHERE句の条件の書き分け：今回の「30日以内」条件を WHERE 句に書くと、LEFT JOINで残されたuser2やuser4の行が除外され、total_users のカウントも変わってしまいます。LEFT JOINの左側の行を消さずに「マッチ条件を絞る」場合は、条件を必ず ON 句に書く必要があります。

実務コラム：コホート分析の実装

コホート分析は「同じ時期に登録したユーザー群がその後どう行動するか」を追跡するSaaS・ECの基本指標です。今回の「30日以内の初回購入率」のほか、「登録から90日後の継続率」「登録月別の累計売上」なども同じCTE+JOIN構造で実装できます。CTEは複数連結して WITH a AS (...), b AS (...) SELECT … FROM a JOIN b のように書けるため、さらに多段階の分析にも対応できます。

QUESTION 10

関係除算的 JOIN — 同一テーブルを複数回 JOIN して「AかつB」を満たす行を抽出する

INNER JOIN自己結合関係除算複数条件AND

前提知識 ▼

「商品Aと商品Bの両方を購入したことがあるユーザーを探せ」という問題は、単純な WHERE … IN では解けません。なぜなら1行は1購入しか表さないため、「1行が同時に商品AであるかつBでもある」という矛盾した条件になるからです。

解決策は2つあります。

-- ① 同一テーブルを2回 SELF JOIN して、p1=商品A と p2=商品B を「横に並べる」
FROM purchases AS p1
INNER JOIN purchases AS p2
  ON  p1.user_id = p2.user_id
WHERE p1.product_code = 'A' AND p2.product_code = 'B'

-- ② HAVING で集計してから絞り込む（別解・商品数が多い場合に有効）
SELECT user_id FROM purchases
WHERE  product_code IN ('A', 'B')
GROUP BY user_id
HAVING COUNT(DISTINCT product_code) = 2

関係除算（Relational Division）：「指定した全ての項目を満たすグループを探す」操作は関係代数の「除算」に相当します。商品が3つ以上に増えた場合は、JOINを追加するかHAVING COUNT = 3 のように変えるだけで対応できます。

問題 ▼

ユーザーの購入履歴テーブル（purchases）があります。各行は「あるユーザーが特定の商品を1回購入した」という1レコードです。

商品コード 'A' と商品コード 'B' の両方を購入したことがあるユーザーの user_id を抽出してください。

使用テーブル

▸ purchases

user_id	product_code
1	A
1	B
1	C
2	A
3	B
4	A
4	B

期待出力 ▼

user_id
1
4

模範解答コード ▼

SELECT DISTINCT
  p1.user_id

FROM purchases AS p1
INNER JOIN purchases AS p2    -- 同じテーブルを p2 として自己結合 (SELF JOIN)
  ON p1.user_id = p2.user_id
WHERE p1.product_code = 'A'   -- p1が商品A、かつ同一ユーザーのp2が商品B の組み合わせだけを残す
  AND p2.product_code = 'B'
ORDER BY p1.user_id;

/*
  実行順序:
  1. FROM purchases AS p1         → 全購入履歴
  2. INNER JOIN purchases AS p2   → 同一テーブルを p2 として自己結合
  3. WHERE p1.product_code = 'A'  → p1 側が商品A の行に絞る
  4. SELECT DISTINCT p1.user_id   → 重複を除去してuser_idを出力
  */

解説（テーブル変化・ポイント） ▼

SELECT DISTINCT
  p1.user_id
FROM purchases AS p1
INNER JOIN purchases AS p2
  ON p1.user_id = p2.user_id
WHERE p1.product_code = 'A'
  AND p2.product_code = 'B';

LEGEND ▼

データ取得・読込対象

① FROM ▼

FROM purchases AS p1全購入履歴（7行）をp1として読み込みます。各行は「誰が何を買ったか」を表します。

1 / 4

user_id	product_code
1	'A'
1	'B'
1	'C'
2	'A'
3	'B'
4	'A'
4	'B'

全 7行読込

学習ポイント

JOIN PATTERN

関係除算的 JOIN（自己結合 × 複数条件）

同一テーブルを複数の視点で自己結合して「かつ」条件を満たす行を抜く
p1 = 商品A の購入行 p2 = 商品B の購入行

「同一テーブルを複数の視点で見る」という発想：SQLのJOINは「異なるテーブルをつなぐ」だけでなく、「同じテーブルを複数の役割として並べる」ことができます。p1=「商品Aを買った事実」p2=「商品Bを買った事実」と捉え、同じuser_idで横につなぐことで「AかつB」という複数行にまたがる条件を1つのSELECTで評価できます。

HAVING を使った別解との使い分け：条件の商品が2つならSELF JOINでもHAVINGでも書けますが、商品が3つ以上になるとSELF JOINはクエリが膨大になります。その場合は HAVING COUNT(DISTINCT product_code) = N のアプローチが保守性に優れます。ただし「どの商品の組み合わせか」を一度に把握したい場合はSELF JOINの方が直感的です。

アンチパターン

OR / IN で「かつ」を表現しようとする：WHERE product_code IN ('A', 'B') は「AまたはB」の条件です。user2(Aのみ)やuser3(Bのみ)も含まれてしまいます。「かつ（AND）」を複数行にまたがって評価するには、必ずSELF JOINかHAVINGを使う必要があります。

DISTINCT の忘れ：SELF JOINにより、user1はA行×B行のペアが1通り、user4も同様に1通りずつ生成されます。しかし商品Cなど他の商品も持つユーザーが増えると組み合わせが重複して複数行が生成される可能性があります。SELECT DISTINCT を常に付けることを習慣にしましょう。

実務コラム：複数条件マッチング

「複数条件を同時に満たすレコードの抽出」はECのリコメンド（「商品Aを買ったユーザーへ商品Bをレコメンド」）や、マーケティングの施策分析（「キャンペーンAとキャンペーンBの両方に参加したユーザーのLTVを分析する」）など、実務のデータ分析で非常に頻繁に登場します。SQLのJOINが「横方向のデータ結合」だけでなく「複数行にまたがる論理積（AND）」を表現できる道具であることを、このパターンを通して理解してください。