SQLのdistinctとgroup byの実行速度についてまとめています。
以下、データベースとして、MySQLのサンプルデータベースEmployeesを使っています
distinctとgroup byで速度差がでるサンプルSQL
下記は、employees（社員）テーブルから、姓名の名と性別を重複なしで抽出するSQLです。上位100件のみ出力しています。
mysql> SELECT distinct first_name, gender FROM `employees` limit 100; +-------------+--------+ | first_name | gender | +-------------+--------+ | Georgi | M | | Bezalel | F | | Parto | M | | Chirstian | M | | Kyoichi | M | | Anneke | F | : : 100 rows in set (0.01 sec)
同じ結果を出力するSQLをgroup byを使って記述するとこうなります。
mysql> SELECT first_name, gender FROM `employees`
-> group by first_name, gender limit 100;
+-------------+--------+
| first_name | gender |
+-------------+--------+
| Georgi | M |
| Bezalel | F |
| Parto | M |
| Chirstian | M |
| Kyoichi | M |
| Anneke | F |
:
:
100 rows in set (27.55 sec)
単純計算で2700倍以上の速度差が出ています。単純にデータの種類だけを出力するなら、distinctを使った方が圧倒的に速そうです。
【関連記事】
▶SQL distinctのサンプルコード集 group byよりも700倍速い？
distinctとgroup ｂｙの実行計画をチェック
distinctとgroup byを使ったSQLをそれぞれexplainしたところ以下の結果となりました。
まずはdistinctを使ったSQL。type=ALLとなっているのでテーブルフルスキャン（全件検索）が起こっています。
mysql> explain SELECT distinct first_name, gender FROM `employees`; +----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+ | 1 | SIMPLE | employees | NULL | ALL | NULL | NULL | NULL | NULL | 299246 | 100.00 | Using temporary | +----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+ 1 row in set, 1 warning (0.00 sec)
group byを使ったSQLをexplainするとこうなります。なんと、distinctの場合と全く同じ実行計画です。
mysql> explain SELECT first_name, gender FROM `employees`
-> group by first_name, gender;
+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+
| 1 | SIMPLE | employees | NULL | ALL | NULL | NULL | NULL | NULL | 299246 | 100.00 | Using temporary |
+----+-------------+-----------+------------+------+---------------+------+---------+------+--------+----------+-----------------+
1 row in set, 1 warning (0.00 sec)
explainの結果だけを見て判断してしまうと「どちらでも同じ」と考えてしまいそうですね。要注意です。
なお、joinするような場合はdistinctよりもexistsを使うとさらに速いという情報や、場合によってはgroup byの方が速いという情報もあり、単純に決めるのは難しそう。
参考）重複行のまとめ方はGROUP BY？DISTINCT？ – Qiita
全件検索せざるをえないような遅くなりそうなクエリでは、explainによる実行計画だけで判断せず、ある程度の件数のテストデータを使ってレスポンスの違いを観察する必要があります。
まとめ
ポテパンダの一言メモ
- 単純な全件検索では、distinctがgroup byよりも速い
- joinする場合はdistinctよりもexistsを使った方が速いケースもあり
- explainの結果が全く同じでもレスポンスが大きく違うことがあるため、実際にデータを使ったレスポンステストが必要
