SQLでの最大値を持つレコードの取得方法について

Question

題名の通りなのですが、あるグループ毎にあるカラムの値が最大のレコードを取得する方法についての質問です。
調べたり自分で考えてみたところ

SELECT *
FROM
	(
		SELECT *
		FROM product
		ORDER BY price DESC
	) product
GROUP BY type

SELECT *
FROM product
INNER JOIN(
		SELECT MAX(price) AS max_price,
		*
		FROM product
		GROUP BY type
	) tmp
ON product.id = tmp.id
AND product.price = tmp.max_price

SELECT *
FROM product
WHERE product.price = (
		SELECT MAX(price)
		FROM product AS tmp
		WHERE product.type = tmp.type
	)

SELECT *
FROM product
WHERE NOT EXISTS(
		SELECT 1
		FROM product AS tmp
		WHERE product.type = tmp.type
		AND product.price < tmp.price
	)

とりあえずこれだけの方法がありました。
どれがコストなどの観点から見て良いものなのでしょうか？
またこれらより優れた方法があれば教えていただきたいです。

Answer 1

Postgresでのテストですので参考まで
SQL文は上から順に（１）（２）（３）（４）としました。
※SQL文の1番目のものは、PostgresではSQLエラーでした。ですので対象外といたしました。
postgresでは * のgroup byができませんし、出力順が保証されていません。

検査対象件数は1万件としました。（インデックスは有りません）
結果は、costを実行時間とすると、早いもの順で（４）＜（２）＜（３）となります。
特に（３）は、条件の部分でSQLその都度実行される事により、他の2つより大変時間が掛かる結果となっています。

EXPLAIN ANALYZEの結果
Execution time:実行時間です（ミリ秒）

NO.2
                                                               QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=230.30..1015.16 rows=56 width=12) (actual time=48.100..85.661 rows=3383 loops=1)
   Hash Cond: ((product.type = product_1.type) AND (product.price = (max(product_1.price))))
   ->  Seq Scan on product  (cost=0.00..167.20 rows=11220 width=12) (actual time=0.017..15.101 rows=10001 loops=1)
   ->  Hash  (cost=227.30..227.30 rows=200 width=8) (actual time=48.040..48.040 rows=3334 loops=1)
         Buckets: 4096 (originally 1024)  Batches: 1 (originally 1)  Memory Usage: 163kB
         ->  HashAggregate  (cost=223.30..225.30 rows=200 width=8) (actual time=36.361..42.345 rows=3334 loops=1)
               Group Key: product_1.type
               ->  Seq Scan on product product_1  (cost=0.00..167.20 rows=11220 width=8) (actual time=0.007..16.087 rows=10001 loops=1)
 Planning time: 0.329 ms
 Execution time: 90.400 ms
(10 rows)

NO.3
                                                        QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
 Seq Scan on product  (cost=0.00..2192583.25 rows=56 width=12) (actual time=4.054..12745.577 rows=3383 loops=1)
   Filter: (price = (SubPlan 1))
   Rows Removed by Filter: 6618
   SubPlan 1
     ->  Aggregate  (cost=195.39..195.40 rows=1 width=4) (actual time=1.235..1.246 rows=1 loops=10001)
           ->  Seq Scan on product tmp  (cost=0.00..195.25 rows=56 width=4) (actual time=0.577..1.174 rows=3 loops=10001)
                 Filter: (product.type = type)
                 Rows Removed by Filter: 9998
 Planning time: 0.143 ms
 Execution time: 12776.098 ms
(10 rows)

NO.4
                                                         QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
 Hash Anti Join  (cost=307.45..667.49 rows=9350 width=12) (actual time=36.436..78.295 rows=3383 loops=1)
   Hash Cond: (product.type = tmp.type)
   Join Filter: (product.price < tmp.price)
   Rows Removed by Join Filter: 14529
   ->  Seq Scan on product  (cost=0.00..167.20 rows=11220 width=12) (actual time=0.011..15.269 rows=10001 loops=1)
   ->  Hash  (cost=167.20..167.20 rows=11220 width=8) (actual time=36.365..36.365 rows=10001 loops=1)
         Buckets: 16384  Batches: 1  Memory Usage: 519kB
         ->  Seq Scan on product tmp  (cost=0.00..167.20 rows=11220 width=8) (actual time=0.009..18.940 rows=10001 loops=1)
 Planning time: 0.164 ms
 Execution time: 83.163 ms
(10 rows)

（２）につきましてもPostgres都合上、下記に修正いたしました。

SELECT product.*
FROM product
INNER JOIN(
        SELECT type, MAX(price) AS max_price
        FROM product
        GROUP BY type
    ) tmp
ON product.type = tmp.type
AND product.price = tmp.max_price;

Comments

[退会済みユーザー]

丁寧な回答ありがとうございます！参考にさせていただきます

Answer 2

1つ目のSQLはGROUP BYで指定されておらず、集約関数でもリテラルでもないカラムをSELECT句に含むため、文法エラーになると思われます。MySQLだとエラーにならないかもしれませんが、それでも正しい結果は保障されません。

その他のSQLではどれかが決定的に早い or 遅いというものはないと思います。入っているデータ（統計情報）、張られている索引、DBMS次第でどれがベストかは変わってくるので、実行計画を確認するのが一番です。

Comments

[退会済みユーザー]

1つ目のような書き方は駄目だったんですね…

Answer 3

各クエリの実行計画をしらべればどれが低コストなのかがわかると思いますが。

Comments

[退会済みユーザー]

全くの初心者なもので実行計画というものすら知りませんでした。すみません。