the - MySQL: no está en GROUP BY

only_full_group_by mysql ubuntu

Question

El sitio produce resultados, pero con SELECT COUNT y SELECT query con GROUP BY que tiene dos recuentos de resultados diferentes. Esto probablemente se deba al error que se muestra en phpmyadmin pero no en el sitio.

Las consultas:

SELECT count(DISTINCT `name`) as `numrows` FROM `users` WHERE `verified` = ''1''

SELECT `name`, `type`, `language`, `code` FROM `users` WHERE `verified` = ''1'' GROUP BY `name` ORDER BY `count` DESC LIMIT 0, 25

PhpMyAdmin proporciona el siguiente error:

1055 - ''main.users.type'' no está en GROUP BY

Al leer documentos de MySQL, todavía no estoy claro qué es lo que tengo que arreglar. Parece que no puedo entender esto.

Answer 1

La mejor solución a este problema es, por supuesto, usar una expresión GROUP BY completa.

Pero hay otra solución que funciona alrededor del bloqueo ONLY_FULL_GROUP_BY de la antigua extensión MySQL a GROUP BY .

SELECT name, 
       ANY_VALUE(type) type,
       ANY_VALUE(language) language,
       ANY_VALUE(code) code 
  FROM users  
 WHERE verified = ''1'' 
 GROUP BY name 
 ORDER BY count DESC LIMIT 0, 25

ANY_VALUE() declara explícitamente lo que solía estar implícito en las operaciones incompletas GROUP BY MySQL: que el servidor puede elegir, bueno, cualquier valor para devolver.

Answer 2

Lo primero es ver por qué es así. Las versiones anteriores nos permitieron ser un poco negligentes: mientras que los valores de la columna agrupada se enumeran por completo (uno de cada uno sin excepciones) en el resultado, los valores de las otras columnas seleccionadas se omiten más o menos, pero el código puede No (no quiere) decir cuáles en su nombre:

- Hey, MYSQL, list the families of the street - but add a first name as well to every row.
- Okay sir, but shall I use the father''s or the mother''s or...? I''m a machine, give exact orders!

Ahora que entendemos el por qué, podemos decidir si tenemos preferencias con respecto a las otras columnas. Utilizar

MAX() AS
MIN() AS
etc, works with strings, too

o si realmente es todo lo mismo, por ejemplo, no hay diferencia entre los valores no agregados que están relacionados con el agrupado, use

ANY_VALUE() AS

De cualquier manera, le haces saber a mysql que eres consciente de ser "equívoco" pero que realmente no quieres enfocarte en todas las columnas que no sean las agrupadas.

Answer 3

Necesitas tener un grupo completo por:

SELECT `name`, `type`, `language`, `code` 
FROM `users` 
WHERE `verified` = ''1'' 
GROUP BY `name`, `type`, `language`, `code` 
ORDER BY `count` DESC LIMIT 0, 25

SQL92 requiere que todas las columnas (excepto los agregados) en la cláusula select sea parte del grupo por cláusula. SQL99 afloja un poco esta restricción y establece que todas las columnas de la cláusula select deben depender funcionalmente del grupo por cláusula. MySQL por defecto permite el grupo parcial por y esto puede producir respuestas no deterministas, por ejemplo:

create table t (x int, y int);
insert into t (x,y) values (1,1),(1,2),(1,3);
select x,y from t group by x;
+------+------+
| x    | y    |
+------+------+
|    1 |    1 |
+------+------+

Es decir, un y aleatorio se selecciona para el grupo x. Se puede evitar este comportamiento configurando @@ sql_mode:

set @@sql_mode=''ONLY_FULL_GROUP_BY'';
select x,y from t group by x; 
ERROR 1055 (42000): ''test.t.y'' isn''t in GROUP BY

Answer 4

Otra solución mencionada varias veces anteriormente es desactivar ese molesto ''ONLY_FULL_GROUP_BY'', por ejemplo, como en esta publicación: Deshabilitar ONLY_FULL_GROUP_BY

Creo que esta solución es muy útil si no desea refactorizar todo el proyecto durante varias horas. Y si no le importan los valores impredecibles de las columnas que no son una lista de GROUP BY .

Answer 5

Simplemente deshabilite la rigurosidad para la consulta.