MySQL 5.6 リファレンスマニュアル  /  ...  /  特定のカラムのグループごとの最大値が格納されている行

3.6.4 特定のカラムのグループごとの最大値が格納されている行

タスク: 物品ごとに最高値を付けている業者 (複数可) を調べます。


SELECT article, dealer, price
FROM   shop s1
WHERE  price=(SELECT MAX(s2.price)
              FROM shop s2
              WHERE s1.article = s2.article);

| article | dealer | price |
|    0001 | B      |  3.99 |
|    0002 | A      | 10.99 |
|    0003 | C      |  1.69 |
|    0004 | D      | 19.95 |

この例では相関サブクエリーを使用していますが、これは十分でない場合があります (セクション13.2.10.7「相関サブクエリー」を参照してください)。この問題を解決する別の方法は、FROM 句または LEFT JOIN で非相関サブクエリーを使用することです。


SELECT s1.article, dealer, s1.price
FROM shop s1
  SELECT article, MAX(price) AS price
  FROM shop
  GROUP BY article) AS s2
  ON s1.article = s2.article AND s1.price = s2.price;


SELECT s1.article,, s1.price
FROM shop s1
LEFT JOIN shop s2 ON s1.article = s2.article AND s1.price < s2.price
WHERE s2.article IS NULL;

LEFT JOIN の動作は、s1.price が最大値を取るときに、それより大きい値の s2.price は存在せず、s2 行の値は NULL になることに基づいています。セクション13.2.9.2「JOIN 構文」を参照してください。

Download this Manual
EPUB - 7.5Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb
User Comments
  Posted by Kasey Speakman on October 3, 2009
The examples here by MySQL are not that helpful if you are working with temporary tables and need to add conditions to the query... like prices only from this year, for instance.

The first example falls down with temporary tables because you can't select from the same temp table twice in the same query (get "can't reopen table" error). It also doesn't give you just distinct articles, if that's what you were after. It will show the same article twice in the case where you have 2 articles from different dealers for the same price.

The second example is both difficult to understand and cumbersome to manage if you have extra query conditions (i.e. don't want to select the whole table). With large tables, you will end up needing to repeat query conditions in inner and outer queries (or at least in the LEFT JOIN ON part) for query speed.

I found another method for group-wise max that is a bit more straightforward and less duplicating of conditions:

FROM shop
[WHERE conditions]
GROUP BY article

The inner query orders all records by highest price. The outer query uses a group by, which simply grabs the first distinct article that it finds. In this case the first one it finds will be the highest one since we ordered them that way.

This query is probably not as efficient as others, but it's straightforward, and it's easier on query developers when they need to use temp tables or needed to query on less than an entire table. It's only slightly less efficient than the queries given by MySQL on this page, in my tests.
  Posted by Robin Palotai on October 17, 2009
Speakman: Your solution sounds good, but is it stable?
The manual tells that non-grouped fields have an indeterminate value if not all values of rows are the same.

Right now the value at the first encountered row may be used, but may it happen in the future releases that other random row will be selected? It would be nice to hear an insider's opinion.
  Posted by O T on November 19, 2009
I suggest the following syntax which orders by column1 as usual but returns the corresponding column2 when given:

max( column1 [, column2 ] )
  Posted by Rick James on December 7, 2009
Speakman's solution ("group by trick", as I call it) is stable and far more efficient than the methods given in the article.

This is Order(N*logN); the article is Order(N*N). That is, as the number of rows grows, the article's methods slow down quadratically -- a million rows would require a trillion operations.
  Posted by Alexandru Trandafir Catalin on April 21, 2010
I think of an easy way to get the row with the greatest value for one field, I don't know if it is efficient but it's sure very easy:


And that's all, it will give you the product with the biggest price.
  Posted by Charlie Chambers on July 13, 2010
Alexandru Trandafir Catalin:
The query you provide is finding the greatest price for any article, i.e. a single value.
The problem that the page is targeted toward is finding the greatest price for each article, i.e. one value per article in the table.

  Posted by Francisco Tirado on December 30, 2010
O T: Although that would be awesome, it did not work for me and I couldn't find it in the manual.
  Posted by Deon Kuhn on February 9, 2012
In my particular case I was only working with one record, and the correlated sub query solution proved 50% faster than the 'group by' trick. I am getting the most recent record to be altered by user 6 by way of a main table and changes log.

FROM main_table iA
JOIN log_table iC ON iA.tid = iC.tid AND iC.userid = 6
WHERE iC.status = 1 AND = ( SELECT MAX( id ) `scmax` FROM log_table WHERE iA.transactionID = trxid )

was faster than

FROM main_table iA
JOIN ( SELECT id, tid, userID FROM ( SELECT id, tid, userID FROM log_table WHERE userID = 6 ORDER BY id DESC ) iiA GROUP BY tid ) iC ON iA.tid = iC.tid AND iC.status = 1

  Posted by Daniel Bermudez on November 7, 2012
I am using this as a tutorial and tried doing it by myself before seeing the "answer" and I came up with this:

WHERE price IN (SELECT MAX(price)
FROM shop GROUP BY article);

I think is very straightforward and easy to understand but I might be missing something.

Why nobody recommended this?
  Posted by Thibault Delor on November 15, 2012
@Daniel Bermudez :
You can find your query there :

"Why nobody recommended this?" :
1) it doesn't do what we want there
2) it is slow
  Posted by Predrag Bradaric on January 25, 2013
I agree with Robin Palotai. Example given by Kasey Speakman is "unreliable" in the long run.
As stated in MySQL reference manual ( values chosen by GROUP BY extension are indeterminate - it is not "guaranteed" that first row (top->down) with distinct value will be chosen in the final result.
Granted, tests have shown that (at the moment) MySQL server will choose first row (top->down) that it encounters but that can break in any future update.
  Posted by John Pratt on March 5, 2014
Perhaps a future version of MySQL will no longer be "indeterminate". It would be easier to write this query if the Select would reliably always select the top row.
Sign Up Login You must be logged in to post a comment.