MySQL分组查询最新的一条记录

问题描述

使用关键字 group by，和order by，但是直接在查询语句后跟上group和order会失效
举例说明：table表中的每个code最新的一条数据
失效写法：

   SELECT t.`value`,t.create_time ,t.codeFROM (SELECT a.code,a.`value`,a.create_timeFROM `table` aORDER BY a.create_time DESC) tGROUP BY t.code;

失效原因：

在mysql5.7手册的8.2.2.1中解释：
子查询的优化是使用半连接的策略完成的(The optimizer uses semi-join strategies to improve subquery execution)
使用半连接进行优化，子查询语句必须满足一些标准(In MySQL, a subquery must satisfy these criteria to be handled as a semi-join)。
其中一个标准是:必须不是一个包含了limit和order by的语句(It must not have ORDER BY with LIMIT.)

生效写法

成功写法一：添加limit

由上述文档解释得到，同时拥有limit和order by的子查询是不会忽略排序的，所以添加limit可以成功分组查询最新。
但是有弊端：limit的n写多少合适？如果该需求是个分页列表，如何实现？因此不是最优解

   SELECT t.`value`,t.create_time ,t.codeFROM (SELECT a.code,a.`value`,a.create_timeFROM `table` aORDER BY a.create_time DESC LIMIT #{n}) tGROUP BY t.code;

成功写法二：通过子查询中包含group by语句

我们知道仅仅拥有order by的子查询会被放到外层排序，因此可不可以直接进行分组并排序，不过问题是：mysql的执行顺序order by语句是在group by之后执行的，这个怎么解决？
解决思路：首先分组排序功能在表中的体现一定是两个字段，分组字段(例如用户id，菜单code)和排序字段(创建时间，更新时间)。想一下：子查询中先对排序字段、分组字段进行分组，后跟上order by ，最外层再次根据分组字段分组。分组时字段谁先谁后无影响。
那这不是无效分组了？其实不然，这样做是为了将子查询的排序生效，这个时候添加order by语句，可以试试，是不是成功的在子查询里进行排序了？

   SELECT t.`value`,t.create_time ,t.codeFROM (SELECT a.code,a.`value`,a.create_timeFROM `table` aGROUP BY a.create_time ,a.codeORDER BY a.create_time ) tGROUP BY t.code;

成功写法三：通过子查询中包含聚合函数

在子查询中使用聚合函数，可以消除合并查询的优化。

   SELECT t.`value`,t.create_time ,t.codeFROM (SELECT a.code,DISTINCT(a.id),a.`value`,a.create_timeFROM `table` aORDER BY a.create_time ) tGROUP BY t.code;

order by 生效的原理

方法二、三中order by 生效的原理：临时表命名后定义为派生表（derived table），Mysql的查询优化器会自动优化sql，并且把派生表合并到外层查询中。

并不是所有带有派生表的查询都能被成功的和外层查询合并，当派生表中有这些语句就不能够和外层查询合并：

含有聚集函数，比如MAX()、MIN()、SUM()之类的
使用DISTINCT去重关键字使用GROUP BY分组关键字
使用HAVING关键字
使用LIMIT关键字
使用UNION 或者 UNION ALL关键字
派生表对应的子查询的SELECT子句中含有另一个子查询

针对order by mysql5.7的文档特殊提到了: 官方文档：8.2.2.4 ，不满足以下三个条件时，派生表会优化order by语句。

The optimizer handles derived tables and view references the same way: It avoids unnecessary materialization whenever possible, which enables pushing down conditions from the outer query to derived tables and produces more efficient execution plans. (For an example, see Section 8.2.2.2, “Optimizing Subqueries with Materialization”.)If merging would result in an outer query block that references more than 61 base tables, the optimizer chooses materialization instead.The optimizer propagates an clause in a derived table or view reference to the outer query block if these conditions are all true: ORDER BY
优化程序传播子句 在派生表或视图中对外部查询块的引用 如果这些条件都为真：ORDER BY1. The outer query is not grouped or aggregated.
外部查询不会分组或聚合。2. The outer query does not specify , , or . DISTINCT HAVIN GORDER BY
外部查询未指定关键字DISTINCT HAVING ORDER BY3. The outer query has this derived table or view reference as the only source in the clause. FROM
外部查询具有此派生表或视图引用 作为子句中的唯一来源。FROMOtherwise, the optimizer ignores the clause. ORDER BY
否则，优化程序将忽略该子句。ORDER BY