group byとdistinct

select COMPANY from USERS group by COMPANY

こんな感じのSQLがありました。

少し考えて理解しました。
テーブル「USERS」中に出てくる COMPANY の値の一覧を取得するための SQL だと。

ちなみに、同じことはコレでも出来ます。

select distinct COMPANY from USERS

というか、こっちが命令の意味的には合っています。

distinct … 同じ内容のレコードを１つにまとめるための命令
group by … 結果を集計するためレコードをグループ化するための命令。

group by で指定したフィールドの値が等しいものは同じグループに入れられてしまうので、結果として、同じ内容のレコードを１つにまとめる効果もあるわけです。

重複データをまとめる専用の命令が distinct で、group by は副作用です。

で、ちょっと調べてみると、distinct と group by のどちらが良いか比較しているページが沢山見つかりました。
そして、
「group by の方が速い」と結論を出している所が非常に多いのにビックリ。

そんなわけないじゃん。

専用命令(distinct)が、副作用の処理(group by)より遅いはずが無いといった単純な理由じゃなくて。

RDBSを作っているメーカ（例えばOracleとか）は、少しでもレスポンスを良くするため改良を続けているのに、より速い実装が目の前にあってノーリスクで利用できるのに、それを使わないなんてありえない。

具体的に言えば、
もし重複データをまとめる処理が distinct より group by の方が速いのだとしたら、内部で group by に置き換えてしまえば group by と同等のレスポンスが得られるというのに、なぜそれをやらないのかと小一時間…

分かりにくい例で例えるのなら…

何でも上手にこなす「ガチ○ピン」と、床掃除しかできない「ム○ク」がいました。

コレしか取り柄がないのだから、床掃除はム○クの方が上手だと思われていたのですが、ある日、床掃除もガチ○ピンの方が上手い事が判明しました。

困ったプロダクションは、
ム○クの中の人をクビにして、ガチ○ピンの中の人に両方の中の人を担当させることにしました。

一方、
もし、ム○クの方が床掃除が上手だとしても、床掃除の時だけガチ○ピンの中の人を入れ替えるかどうかは、入れ替えの手間がどれくらいかかるかで、やったりやらなかったりするわけです。

あなたは、どっちに床掃除を依頼しますか？

---

そこで、改めて「group by の方が速い」との主張を見てみると……

distinct を使ったSQLと group by を使ったSQL で同じことをさせていない
もしくは、
集計処理っぽいことを distinct を駆使して実現していたりしました。

タグ：SQL