DISTINCTは「思考停止の解決策」ではない
日々の開発やデータ分析において、クエリ結果の重複を排除するために DISTINCT を使う場面は非常に多いはずです。しかし、実務の現場において「とりあえず重複を消すためにDISTINCT」という思考でSQLを書くのは、パフォーマンスを劇的に悪化させる大きなリスクを孕んでいます。なぜなら、DISTINCTは内部的に ソートやハッシュ処理による重複排除の負荷 を強制的に発生させるからです。
なぜDISTINCTでパフォーマンスが落ちるのか
データベースエンジンは、DISTINCTが指定されると、すべての対象データをメモリ（または一時領域）に展開し、並び替えやグルーピングを行ってから重複を削除します。データ量が数万件程度であれば一瞬ですが、数百万件を超えるテーブルでこれを実行すると、CPUとメモリのリソースを大量に消費します。特にインデックスが効かない条件でDISTINCTを実行すると、フルテーブルスキャンが重なり、システム全体のレスポンスを著しく低下させる原因となります。
実務で使える「賢い代替案」
重複を排除したいという目的は同じでも、アプローチを変えるだけでクエリの実行速度は大きく改善します。
1. EXISTS句への書き換え
例えば「注文履歴がある顧客の一覧を取得したい」という場合、DISTINCTを使うと全ての注文履歴をスキャンして重複を消す処理が走ります。代わりに EXISTS を使えば、対象の注文レコードが「1件でも見つかった時点でスキャンを打ち切る」ため、圧倒的に高速です。
2. GROUP BYの活用と意図の明確化
単に重複を消すだけでなく、集計処理を伴う場合はGROUP BYの方が意図が明確です。また、特定のカラムのみをユニークにしたい場合、ウィンドウ関数（ROW_NUMBER()など）を使って「特定の条件で最も新しいレコードを1件だけ取得する」といった処理を行う方が、DISTINCTよりも制御が容易で保守性も高まります。
3. インデックス設計の再考
そもそも重複が発生する理由が「結合（JOIN）の多重掛け」にあるケースが多いです。結合先のテーブル構造を見直し、インデックスが適切に貼られていれば、JOINの段階で重複を最小限に抑えることができます。DISTINCTで無理やり消すのではなく、データ取得の入り口で制御するのがDBAとしての正しい姿勢です。
結論：DISTINCTは「最終手段」として扱う
実務において、DISTINCTは禁止事項ではありません。しかし、クエリの実行計画（EXPLAIN）を確認した際、そこに「Using temporary; Using filesort」の文字が出ていないか、常に意識してください。「なぜ重複しているのか」というデータの発生源を特定することこそが、真のチューニングへの第一歩です。安易なDISTINCTに頼る前に、まずはインデックスの活用とロジックの改善を検討してみましょう。
コメント