Quindi vuoi ottenere la riga con il più alto OrderField
per gruppo? Lo farei in questo modo:
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)
( EDIT di Tomas: se ci sono più record con lo stesso OrderField all'interno dello stesso gruppo e ne hai bisogno esattamente uno, potresti voler estendere la condizione:
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
fine della modifica.)
In altre parole, restituisce la riga t1
per la quale non esistono altre righe t2
con la stessa GroupId
e una maggiore OrderField
. Quando t2.*
è NULL, significa che il join esterno sinistro non ha trovato alcuna corrispondenza di questo tipo e quindi t1
ha il valore maggiore di OrderField
nel gruppo.
Niente ranghi, niente sottoquery. Questo dovrebbe essere veloce e ottimizzare l'accesso a t2 con "Using index" se hai un indice composto attivo (GroupId, OrderField)
.
Per quanto riguarda le prestazioni, vedere la mia risposta a Recupero dell'ultimo record in ogni gruppo . Ho provato un metodo di subquery e il metodo di join utilizzando il dump dei dati di Stack Overflow. La differenza è notevole: il metodo di unione è stato eseguito 278 volte più velocemente nel mio test.
È importante che tu abbia l'indice giusto per ottenere i migliori risultati!
Per quanto riguarda il tuo metodo che utilizza la variabile @Rank, non funzionerà come l'hai scritta, perché i valori di @Rank non verranno ripristinati a zero dopo che la query ha elaborato la prima tabella. Ti faccio vedere un esempio.
Ho inserito alcuni dati fittizi, con un campo in più che è nullo tranne che sulla riga che sappiamo essere la più grande per gruppo:
select * from `Table`;
+---------+------------+------+
| GroupId | OrderField | foo |
+---------+------------+------+
| 10 | 10 | NULL |
| 10 | 20 | NULL |
| 10 | 30 | foo |
| 20 | 40 | NULL |
| 20 | 50 | NULL |
| 20 | 60 | foo |
+---------+------------+------+
Possiamo mostrare che il rango aumenta a tre per il primo gruppo e sei per il secondo gruppo, e la query interna li restituisce correttamente:
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 |
+---------+---------+
Ora esegui la query senza condizione di join, per forzare un prodotto cartesiano di tutte le righe e recuperiamo anche tutte le colonne:
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 |
+---------+---------+---------+------------+------+------+
Possiamo vedere da quanto sopra che il ranking massimo per gruppo è corretto, ma poi il @Rank continua ad aumentare mentre elabora la seconda tabella derivata, fino a 7 e oltre. Quindi i ranghi della seconda tabella derivata non si sovrapporranno mai ai ranghi della prima tabella derivata.
Dovresti aggiungere un'altra tabella derivata per forzare @Rank a reimpostare a zero tra l'elaborazione delle due tabelle (e sperare che l'ottimizzatore non cambi l'ordine in cui valuta le tabelle, oppure usa STRAIGHT_JOIN per impedirlo):
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 |
+---------+------------+------+------+
Ma l'ottimizzazione di questa query è terribile. Non può utilizzare alcun indice, crea due tabelle temporanee, le ordina nel modo più duro e utilizza persino un buffer di join perché non può utilizzare un indice nemmeno quando si uniscono tabelle temporanee. Questo è un esempio di output da 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 |
+----+-------------+------------+--------+---------------+------+---------+------+------+---------------------------------+
Considerando che la mia soluzione utilizzando il join esterno sinistro ottimizza molto meglio. Non utilizza tabelle temporanee e persino rapporti, il "Using index"
che significa che può risolvere il join utilizzando solo l'indice, senza toccare i dati.
+----+-------------+-------+------+---------------+---------+---------+-----------------+------+--------------------------+
| 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 |
+----+-------------+-------+------+---------------+---------+---------+-----------------+------+--------------------------+
Probabilmente leggerai persone che affermano sui loro blog che "i join rendono SQL lento", ma non ha senso. Una scarsa ottimizzazione rende l'SQL lento.