同名列で省略して結合 - USING / NATURAL JOIN
同名の結合キーを短く書ける USING と、同名列で自動結合する NATURAL JOIN
概念図
構文
sql
SELECT ... FROM A JOIN B USING (共通列)サンプル
両テーブルで同名の user_id 列を結合キーとして使う（結果では user_id は 1 列に統合）
sql
SELECT user_id, u.name, o.amount
FROM users u
JOIN orders o USING (user_id);USING 句の使いどころ
USING (列) は、両テーブルで同名の列を結合キーとして使うときの短縮記法です。ON a.user_id = b.user_id の代わりに USING (user_id) と書けます。
結果セットでは結合キーが 1 列に統合される点が ON と異なります（ON では左右両方の列が出る）。複数列でも USING (a, b) のように書けます。
ON との比較
- ON: 任意の結合条件を書ける。列名が違ってもよい。結合キーは左右とも結果に残る
- USING: 同名列のみ。結合キーは 1 列にまとまる。
SELECT *で冗長な列が出ない - 列名を明示する場合、USING で指定した列は テーブル修飾なしで参照する（
u.user_idではなくuser_id）
NATURAL JOIN とは
NATURAL JOIN は 両テーブルに存在する全ての同名列を自動的に結合キーとして使います。ON も USING も書きません。一見便利ですが実務ではほぼ非推奨です。
sql
-- 両テーブルに user_id と created_at があると両方が結合キーになる
SELECT * FROM users NATURAL JOIN orders;NATURAL JOIN の危険性
- 暗黙の結合キー: テーブルに同名列（
created_at,updated_at,status等）が偶然あると、それも結合キーに含まれてしまい結果が激減する - スキーマ変更に弱い: ALTER TABLE で列を追加しただけでクエリの挙動が変わる
- 可読性が低い: 何をキーに結合しているかクエリからは分からない
- SQL Server は NATURAL JOIN 自体をサポートしない
代わりに USING か ON を明示的に書きましょう。
RDBMS 対応状況
- USING: PostgreSQL / MySQL / SQLite / Oracle でサポート。SQL Server は未対応（ON を使う）
- NATURAL JOIN: PostgreSQL / MySQL / SQLite / Oracle がサポート。SQL Server は未対応