获得每组最高/最小的logging

怎么做?

这个问题以前的标题是“ 在使用子查询的复杂查询中使用rank(@Rank:= @Rank + 1) – 是否可以工作? ”因为我正在寻找使用等级的解决scheme,但是现在我看到Bill发布的解决scheme是好多了。

原始问题:

我试图编写一个查询,将从每个组中给出一些定义的顺序最后一个logging:

SET @Rank=0; select s.* from (select GroupId, max(Rank) AS MaxRank from (select GroupId, @Rank := @Rank + 1 AS Rank from Table order by OrderField ) as t group by GroupId) as t join ( select *, @Rank := @Rank + 1 AS Rank from Table order by OrderField ) as s on t.GroupId = s.GroupId and t.MaxRank = s.Rank order by OrderField 

expression式@Rank := @Rank + 1通常用于排名,但对于我来说,在2 @Rank := @Rank + 1查询中使用时看起来很可疑,但只初始化一次。 它会这样工作吗?

第二,它是否会与多次评估的子查询一起工作? 像子查询中的where(或having)子句(另一种方式如何写上述):

 SET @Rank=0; select Table.*, @Rank := @Rank + 1 AS Rank from Table having Rank = (select max(Rank) AS MaxRank from (select GroupId, @Rank := @Rank + 1 AS Rank from Table as t0 order by OrderField ) as t where t.GroupId = table.GroupId ) order by OrderField 

提前致谢!

所以你想要获得每个组最高OrderField的行? 我会这样做:

 SELECT t1.* FROM `Table` AS t1 LEFT OUTER JOIN `Table` AS t2 ON t1.GroupId = t2.GroupId AND t1.OrderField < t2.OrderField WHERE t2.GroupId IS NULL ORDER BY t1.OrderField; // not needed! (note by Tomas) 

由Tomas编辑:如果在同一组中有相同OrderField的更多logging,并且您只需要其中的一个,则可能需要扩展条件:

 SELECT t1.* FROM `Table` AS t1 LEFT OUTER JOIN `Table` AS t2 ON t1.GroupId = t2.GroupId AND (t1.OrderField < t2.OrderField OR (t1.OrderField = t2.OrderField AND t1.Id < t2.Id)) WHERE t2.GroupId IS NULL 

编辑结束。)

换句话说,使用相同的GroupId和更大的OrderField返回没有其他行t2存在的行t1 。 当t2.*为NULL时,表示左边的外部连接没有find这样的匹配,因此t1中组的OrderField值最大。

没有行列,没有子查询。 如果你在(GroupId, OrderField)上有一个复合索引,这应该运行得很快,并且通过“使用索引”来优化对t2的访问。


关于performance,请参阅我的回答检索每个组中的最后一个logging 。 我尝试了一个子查询方法和使用堆栈溢出数据转储的联接方法。 差异是显着的:在我的testing中,连接方法跑了278倍。

重要的是你有正确的索引,以获得最好的结果!

关于使用@Rankvariables的方法,它不会像你写的那样工作,因为@Rank的值在查询处理完第一个表之后不会重置为零。 我会告诉你一个例子。

我插入了一些虚拟数据,除了我们知道每个组最大的行之外,还有一个额外的字段是空的:

 select * from `Table`; +---------+------------+------+ | GroupId | OrderField | foo | +---------+------------+------+ | 10 | 10 | NULL | | 10 | 20 | NULL | | 10 | 30 | foo | | 20 | 40 | NULL | | 20 | 50 | NULL | | 20 | 60 | foo | +---------+------------+------+ 

我们可以显示第一组和第二组的排名增加到三,内部查询正确地返回这些:

 select GroupId, max(Rank) AS MaxRank from ( select GroupId, @Rank := @Rank + 1 AS Rank from `Table` order by OrderField) as t group by GroupId +---------+---------+ | GroupId | MaxRank | +---------+---------+ | 10 | 3 | | 20 | 6 | +---------+---------+ 

现在运行没有连接条件的查询,强制所有行的笛卡尔乘积,并且我们也获取所有列:

 select s.*, t.* from (select GroupId, max(Rank) AS MaxRank from (select GroupId, @Rank := @Rank + 1 AS Rank from `Table` order by OrderField ) as t group by GroupId) as t join ( select *, @Rank := @Rank + 1 AS Rank from `Table` order by OrderField ) as s -- on t.GroupId = s.GroupId and t.MaxRank = s.Rank order by OrderField; +---------+---------+---------+------------+------+------+ | GroupId | MaxRank | GroupId | OrderField | foo | Rank | +---------+---------+---------+------------+------+------+ | 10 | 3 | 10 | 10 | NULL | 7 | | 20 | 6 | 10 | 10 | NULL | 7 | | 10 | 3 | 10 | 20 | NULL | 8 | | 20 | 6 | 10 | 20 | NULL | 8 | | 20 | 6 | 10 | 30 | foo | 9 | | 10 | 3 | 10 | 30 | foo | 9 | | 10 | 3 | 20 | 40 | NULL | 10 | | 20 | 6 | 20 | 40 | NULL | 10 | | 10 | 3 | 20 | 50 | NULL | 11 | | 20 | 6 | 20 | 50 | NULL | 11 | | 20 | 6 | 20 | 60 | foo | 12 | | 10 | 3 | 20 | 60 | foo | 12 | +---------+---------+---------+------------+------+------+ 

从上面我们可以看出,每个组的最大等级是正确的,但是@Rank在处理第二个派生表的时候继续增加到了7和更高。 所以第二个派生表中的行列绝对不会与第一个派生表中的行列重叠。

您必须添加另一个派生表来强制@Rank在处理这两个表之间重置为零(并希望优化器不会更改它评估表的顺序,否则使用STRAIGHT_JOIN来防止):

 select s.* from (select GroupId, max(Rank) AS MaxRank from (select GroupId, @Rank := @Rank + 1 AS Rank from `Table` order by OrderField ) as t group by GroupId) as t join (select @Rank := 0) r -- RESET @Rank TO ZERO HERE join ( select *, @Rank := @Rank + 1 AS Rank from `Table` order by OrderField ) as s on t.GroupId = s.GroupId and t.MaxRank = s.Rank order by OrderField; +---------+------------+------+------+ | GroupId | OrderField | foo | Rank | +---------+------------+------+------+ | 10 | 30 | foo | 3 | | 20 | 60 | foo | 6 | +---------+------------+------+------+ 

但是这个查询的优化是可怕的。 它不能使用任何索引,它会创build两个临时表,对它们进行艰难的sorting,甚至使用联接缓冲区,因为联接临时表时也不能使用索引。 这是来自EXPLAIN示例输出:

 +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------------------+ | 1 | PRIMARY | <derived4> | system | NULL | NULL | NULL | NULL | 1 | Using temporary; Using filesort | | 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 2 | | | 1 | PRIMARY | <derived5> | ALL | NULL | NULL | NULL | NULL | 6 | Using where; Using join buffer | | 5 | DERIVED | Table | ALL | NULL | NULL | NULL | NULL | 6 | Using filesort | | 4 | DERIVED | NULL | NULL | NULL | NULL | NULL | NULL | NULL | No tables used | | 2 | DERIVED | <derived3> | ALL | NULL | NULL | NULL | NULL | 6 | Using temporary; Using filesort | | 3 | DERIVED | Table | ALL | NULL | NULL | NULL | NULL | 6 | Using filesort | +----+-------------+------------+--------+---------------+------+---------+------+------+---------------------------------+ 

而我使用左外连接的解决scheme优化得更好。 它不使用临时表,甚至报告"Using index" ,这意味着它可以仅"Using index"来parsing连接,而不会触及数据。

 +----+-------------+-------+------+---------------+---------+---------+-----------------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+---------+---------+-----------------+------+--------------------------+ | 1 | SIMPLE | t1 | ALL | NULL | NULL | NULL | NULL | 6 | Using filesort | | 1 | SIMPLE | t2 | ref | GroupId | GroupId | 5 | test.t1.GroupId | 1 | Using where; Using index | +----+-------------+-------+------+---------------+---------+---------+-----------------+------+--------------------------+ 

你可能会读博客上的人声称“joinSQL慢”,但这是无稽之谈。 糟糕的优化使SQL变慢。