SQL Server DISTINCT の3つの罠 — 複数列 / NULL / 大量行で重複排除を間違えない

みなさんこんにちは！ヒロポンです！

一覧画面とか CSV 出力で「重複を消したい」。で、SELECT DISTINCT をペタッと付ける。業務SEなら一度はやりますよね。俺もやる。

ただこの DISTINCT、軽い気持ちで使うと足をすくわれます。「列ごとに効くと思ってた」。「件数が想定と合わない」。「開発機では一瞬なのに本番で急に固まる」。全部 DISTINCT あるあるなんですよね。

ん？ DISTINCT 付けたのに重複が消えてなくない？？ ってやつ。俺も2年目の頃に何回かやらかしました。原因はだいたい、これから書く3つのどれか。

今回は SQL Server DISTINCT で業務SEが実務で踏む3つの罠を、現場でやった話ベースでまとめます。複数列 / NULL / 大量行。最後に GROUP BY・ROW_NUMBER との使い分け早見表も付けるんで、朝礼で「なんで DISTINCT 使ったの？」って詰められた時の弾薬にしてください。

⏱ 対処目安サマリ

• 罠1（複数列） — 結果がおかしい原因の切り分け：5分。GROUP BY か別書き方に変えるだけ
• 罠2（NULL） — 件数のズレ確認：5分。NULL の集約挙動を知ってれば即わかる
• 罠3（大量行で遅い） — 実行計画の確認＋INDEX/GROUP BY 見直し：30分〜

罠1. 複数列に DISTINCT — 列ごとじゃなく「行全体」で効く

一番多い勘違いがこれ。DISTINCT は 指定した列の組み合わせ（行全体）で重複を消す。列ごとに別々には効きません。

-- 部署を一意にしたいつもりで…
SELECT DISTINCT department, status
FROM employees;

これ、department だけの重複排除にはなりません。department と status の ペアが一意になるだけ。同じ部署でも status が違えば、別の行として残る。

-- department だけ一意にしたいなら GROUP BY で集約条件を明示する
SELECT department
FROM employees
GROUP BY department;

こう書けば、部署だけがいい感じに一意になります。DISTINCT と GROUP BY、見た目は似てるのに効く単位がそもそも違うんですよね。

実行結果（DISTINCT 複数列は組み合わせで残る・GROUP BY は部署だけ一意）:

教訓：DISTINCT は「行の重複排除」、列単位の集約がしたいなら GROUP BY。ここを混同すると「DISTINCT 付けたのに重複が残ってる？？」で30分溶かします。

罠2. NULL 同士は1行に集約される

DISTINCT の NULL の扱いは、WHERE の = とは別物。NULL 同士は「同じ値」とみなされて1行にまとまります。

-- bonus に NULL が複数行あっても…
SELECT DISTINCT bonus
FROM employees;
-- → NULL は1行だけ返る（複数の NULL は1つに集約）

WHERE bonus = NULL は1件も返さない。NULL 同士の = は「不明＝偽」だから。なのに DISTINCT だと NULL がまとまる。この非対称が地味にハマる。

実行結果（DISTINCT で NULL は1行に集約・= NULL は0件・COUNT(*) と COUNT(bonus) で件数が違う）:

「NULL を1件として数えたくない」なら、WHERE bonus IS NOT NULL で先に除く。あるいは件数を数える時に COUNT(bonus)（NULL を数えない）を使う。COUNT(*) と COUNT(列) で結果が変わるのも、根っこはこの NULL 挙動です。

ここを押さえとくと、件数が1ズレた時に「あ、NULL か」ってすぐ当たりがつきます。こんな感じで NULL の挙動は、一回腹落ちさせれば一生モノ。

教訓：DISTINCT の NULL は「1行に集約」、= の NULL は「常に偽」。同じ NULL でも、文脈で挙動が真逆になる。

罠3. 大量行では並べ替えコストで遅くなる

開発環境では一瞬。なのに本番で急に固まる。これ、DISTINCT が 内部で全行をソートして重複を潰してるのが原因です。行数が増えると、この並べ替えコストがそのまま効いてくる。

『失敗から学ぶ RDB の歩き方』（曽根 壮大, 第6章「ソートの依存」p.89）でも、ソートが効くクエリで ORDER BY に INDEX を効かせたら 実行時間が 11.51秒 → 0.01秒 まで縮んだ例が出てきます。ポイントは「ソートの処理が不要になる」こと。INDEX の順序をそのまま使えれば、並べ替え自体が消える。

DISTINCT も理屈は同じ。重複排除のためのソートを INDEX で肩代わりできれば、速くなります。

-- 数百万行の orders から customer_id の重複を消す
SELECT DISTINCT customer_id
FROM orders;
-- → customer_id に INDEX が無いと、全行ソートが走って重い