SQLのDISTINCTはEXISTSとかGROUP BYでなんとかする事もできます。
DISTINCTは暗黙的なソートがされますが、何のDBを使うにせよ過去のバージョンならともかく、最近のバージョンでは劇的に速度に差が出るほどではないです。
個人的にはDISTINCTを使える抽出条件の方が目くらでさらっと分かるので好きですが、諸事情で使えないケースもあるため手数は考えておきたいです。使用している特定製品がWHERE以下しかSQLを記述することが出来なくて、DISTINCTの代わりが必要ってレアケースの人もいると思います。
基本的にGROUP BY句が使えるデータ構造と条件であれば、GROUP BYだけやcountなどの組み合わせで終わりです。
EXISTS句で代替ソース書くとこんな感じですが、データの持ち方や結合する抽出条件によるため、その都度調整が必要です。
SELECT a.id,a.name FROM dev_table as a WHERE EXISTS (SELECT * FROM dev_table as b WHERE a.id = b.id)
参考: SQL 副問合せのサンプル(サブクエリ) | (重複行を削除するのがDISTINCTであり、GROUP BYは集合演算)
EXISTS句の利用はデータ構造によってindexが利用されずフルスキャンになるケースが見受けられます。EXISTS句を廃止してjoinとorder byに切り替えられたケースで、オプティマイザの最適な検索条件の見解と一致するなど珍しくはないでしょう。
GROUP BY句はデータの持ち方によって使えるケースが明瞭なのと、余分なディスクIOが発生したり領域利用したり懸念するところが出てきます。
SQLは使ってるDBの種類だけでなくバージョンによってオプティマイザの見解が異なるので難しいところです。ケースバイケースなので、ある程度のレスポンスを気にした書き方にしたら、実装後にサイジングとか負荷試験を行って、環境の最適を探すしかないです。
正直昔はサブクエリのバグ踏んだり、オプティマイザの謎の順位を理解しないで適当に作ると重くなったりと、考えさせられることが多々ありました。最近のバージョンでデータ設計を見落としていた以外で重くなったケースをお目にかからないので、昔よりも考えることは少なくなったのかも知れません。そう考えるともっと冴えた方法があるかも知れませんね。
