Problema

Supongamos que tengo esta mesatab (violín disponible).

| g | a | b |     v |
---------------------
| 1 | 3 | 5 |   foo |
| 1 | 4 | 7 |   bar |
| 1 | 2 | 9 |   baz |
| 2 | 1 | 1 |   dog |
| 2 | 5 | 2 |   cat |
| 2 | 5 | 3 | horse |
| 2 | 3 | 8 |   pig |

Estoy agrupando filas porg, y para cada grupo quiero un valor de la columnav. Sin embargo, no quieroalguna valor, pero quiero el valor de la fila con maximala, y de todas ellas, la de máximo.b. En otras palabras, mi resultado debe ser

| 1 |   bar |
| 2 | horse |

Solución actual

Sé de una consulta para lograr esto:

SELECT grps.g,
(SELECT v FROM tab
 WHERE g = grps.g
 ORDER BY a DESC, b DESC
 LIMIT 1) AS r
FROM (SELECT DISTINCT g FROM tab) grps

Pregunta

Pero considero esta consulta más bienfeo. Sobre todo porque utiliza unasubconsulta dependiente, que se siente como un verdadero asesino de rendimiento. Así que me pregunto si hay una solución más fácil a este problema.

Respuestas esperadas

La respuesta más probable que espero a esta pregunta sería algún tipo de complemento o parche para MySQL (o MariaDB) que proporciona una característica para esto. Pero también daré la bienvenida a otras inspiraciones útiles. Cualquier cosa que funcione sin una subconsulta dependiente calificaría como una respuesta.

Si su solución solo funciona para una única columna de pedido, es decir, no pudo distinguir entrecat yhorse, siéntase libre de sugerir esa respuesta, así como espero que siga siendo útil para la mayoría de los casos de uso. Por ejemplo,100*a+b sería una forma probable de ordenar los datos anteriores por ambas columnas mientras se usa una sola expresión.

Tengo en mente algunas soluciones bastante piratas, y podría agregarlas después de un tiempo, pero primero veré y veré si algunas nuevas y agradables llegan primero.

Resultados de referencia

Como es bastante difícil comparar las distintas respuestas con solo mirarlas, he realizado algunos puntos de referencia en ellas. Esto se ejecutó en mi propio escritorio, utilizando MySQL 5.1. Los números no se compararán con ningún otro sistema, solo entre sí. Probablemente debería hacer sus propias pruebas con sus datos de la vida real si el rendimiento es crucial para su aplicación. Cuando llegan nuevas respuestas, puedo agregarlas a mi script y volver a ejecutar todas las pruebas.

100,000 artículos, 1,000 grupos para elegir, InnoDb:0.166s paraMvG (de la pregunta)0.520s paraRichardTheKiwi2.199s paraxdazz19.24s paraDems (Subconsultas secuenciales)48.72s paraacatt100,000 artículos, 50,000 grupos para elegir, InnoDb:0.356s paraxdazz0.640s paraRichardTheKiwi0.764s paraMvG (de la pregunta)51.50s paraacattdemasiado largo paraDems (Subconsultas secuenciales)100,000 artículos, 100 grupos para elegir, InnoDb:0.163s paraMvG (de la pregunta)0.523s paraRichardTheKiwi2.072s paraDems (Subconsultas secuenciales)17.78s paraxdazz49.85s paraacatt

Así que parece que mi propia solución hasta ahora no es tan mala, incluso con la subconsulta dependiente. Sorprendentemente, la solución por acatt, que también utiliza una subconsulta dependiente y que, por lo tanto, habría considerado casi igual, funciona mucho peor. Probablemente algo que el optimizador de MySQL no puede hacer frente. La solución propuesta por RichardTheKiwi parece tener también un buen desempeño general. Las otras dos soluciones dependen en gran medida de la estructura de los datos. Con muchos grupos pequeños, el enfoque de xdazz supera a todos los demás, mientras que la solución de Dems funciona mejor (aunque todavía no es excepcionalmente buena) para pocos grupos grandes.