MySQLのNOT IN句を徹底解説｜使い方・注意点・NOT EXISTSとの違いもわかりやすく解説

1. MySQLのNOT IN句とは？―除外条件でデータ抽出をもっと便利に

2. NOT INの基本構文と利用例

SELECT カラム名 FROM テーブル名 WHERE カラム名 NOT IN (値1, 値2, ...);

単純なリストによる除外

SELECT * FROM users WHERE name NOT IN ('山田', '佐藤');

サブクエリを使った動的な除外

SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM blacklist WHERE is_active = 1);

複数条件での応用

3. NULL混在時の注意点

NULLを含む場合の挙動

-- users テーブル
id | name
---+------
 1 | 佐藤
 2 | 山田
 3 | 鈴木
 4 | 田中

-- blacklist テーブル
user_id
--------
1
NULL

SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM blacklist);

なぜ何も返らないのか

よくあるトラブル例

対策と回避方法

SELECT * FROM users
WHERE id NOT IN (
  SELECT user_id FROM blacklist WHERE user_id IS NOT NULL
);

• NOT INのリストにNULLがあると、結果が全件返らない場合がある
• サブクエリ＋NOT INでは「IS NOT NULL」でNULL除外を忘れずに
• 「データが取得できない」ときはまずNULL混入を疑う

4. NOT IN vs NOT EXISTS ～代替手段の比較

基本構文の比較

SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM blacklist WHERE user_id IS NOT NULL);

SELECT * FROM users u
WHERE NOT EXISTS (
  SELECT 1 FROM blacklist b WHERE b.user_id = u.id
);

NULL値への強さ

• サブクエリ側やリストにNULLが混ざると、意図通りに動かない（結果が0件になる場合がある）
• 対策として「IS NOT NULL」の条件が必要

• サブクエリの結果にNULLが含まれていても、正しく動作する
• 基本的にNULL値の影響を受けないため、安全性が高い

パフォーマンスの違い

• 小規模データやリストが固定のときはNOT INでも問題ない
• サブクエリが大きい場合や複雑な条件が絡む場合はNOT EXISTSやLEFT JOINの方がパフォーマンスが良いことが多い

使い分けの目安

• NULL値が混入する可能性がある場合 →　NOT EXISTSを推奨
• 固定リストや単純な値の除外のみ →　NOT INでも問題なし
• パフォーマンスを最重視する場合 →　EXPLAINで実行計画を確認し、状況に応じて選択（JOINやNOT EXISTSも検討）

サンプルケース

-- blacklist.user_idにNULLが含まれる場合
SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM blacklist);
-- → 結果が0件になることも

SELECT * FROM users u
WHERE NOT EXISTS (
  SELECT 1 FROM blacklist b WHERE b.user_id = u.id
);
-- → NULLの有無にかかわらず正しく抽出できる

• NOT INはシンプルだが、NULLの混入に弱い
• NOT EXISTSはNULLに強く、実務でもよく使われる
• どちらを使うかは「データ内容」と「求めるパフォーマンス」に応じて使い分ける

5. パフォーマンス上の考察

NOT IN句のパフォーマンスの特徴

• サブクエリ側のデータ件数が多い場合
• 除外対象カラムにインデックスが張られていない場合
• サブクエリにNULL値が混在している場合

インデックス活用の重要性

CREATE INDEX idx_blacklist_user_id ON blacklist(user_id);

NOT INとNOT EXISTSのパフォーマンス比較

• 小規模な固定リスト：NOT INが高速
• サブクエリが大規模：NOT EXISTSやLEFT JOINを使った方が効率的

EXPLAINによる実行計画の確認

EXPLAIN SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM blacklist WHERE user_id IS NOT NULL);

大規模データでの最適化例

• 必要に応じて一時テーブルにデータを格納し、サブクエリの負担を減らす
• どうしても遅い場合はバッチ処理やキャッシュを活用する
• LEFT JOIN ... IS NULLで書き換えてみる（状況によって高速化することがある）

• サブクエリの件数が多い場合やインデックスがない場合はNOT INは遅くなりやすい
• インデックス設計やクエリの見直しでパフォーマンスを大きく改善できる
• NOT EXISTSやLEFT JOINも選択肢として検討し、実際にEXPLAINで効果を確かめる

6. よくある使い方と応用テクニック

複数カラムでの除外（複合キーの除外）

SELECT * FROM orders o
WHERE NOT EXISTS (
  SELECT 1 FROM blacklist b
  WHERE b.customer_id = o.customer_id
    AND b.product_id = o.product_id
);

部分一致（ワイルドカード）除外：NOT LIKEとの併用

SELECT * FROM users WHERE email NOT LIKE 'test@%';

SELECT * FROM users
WHERE email NOT LIKE 'test@%'
  AND email NOT LIKE 'sample@%';

リスト数が多いときの工夫

-- 例：blacklistテーブルに除外リストを保存
SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM blacklist WHERE user_id IS NOT NULL);

集計関数と組み合わせた除外

SELECT * FROM customers
WHERE id NOT IN (
  SELECT customer_id FROM orders
  WHERE order_date >= '2025-06-01'
    AND order_date < '2025-07-01'
);

サブクエリの代わりにJOINを使う例

SELECT u.*
FROM users u
LEFT JOIN blacklist b ON u.id = b.user_id
WHERE b.user_id IS NULL;

• 複数カラムの除外にはNOT EXISTSやJOINが便利
• 部分一致の除外はNOT LIKEと組み合わせる
• サブクエリや一時テーブルでリスト管理をすると運用しやすい
• JOIN＋IS NULLはパフォーマンス改善にもつながる

7. FAQ（よくある質問）

• NULL値の可能性がある場合やサブクエリを使う場合は、NOT EXISTSの方が確実です。
• 固定リストや単純な値の除外にはNOT INでも問題ありません。
• 実行計画やデータ件数によってはパフォーマンスも変わるので、状況ごとに使い分けましょう。

• 除外対象カラムにインデックスを設定する
• サブクエリ内の件数を減らす、または事前に一時テーブルにデータを整理する
• 場合によってはNOT EXISTSやLEFT JOIN ... IS NULLへの書き換えも検討しましょう
• EXPLAINで実行計画を確認し、ボトルネックを特定するのが有効です

• NULL値が混ざっていないかを確認
• サブクエリの結果が期待通りかを個別に実行して確かめる
• WHERE条件やJOINの結び方に誤りがないかチェック
• データベースのバージョンや設定で挙動が異なる場合もあるので、公式ドキュメントも参考にしましょう

8. まとめ

• NOT INは簡単な除外条件に有効
• NULL値の影響には必ず注意（IS NOT NULLの併用を習慣に）
• パフォーマンスが気になる場合はインデックス設計やNOT EXISTS・JOINも選択肢に
• 必ず実行計画（EXPLAIN）で効果をチェック