W MySQL 5.6 można ustawić tryb SQL ONLY_FULL_GROUP_BY, ale nie jest on ustawiony domyślnie (patrz https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html ).
Aha, widzę, że twój komentarz pojawił się powyżej, potwierdziłeś, że ONLY_FULL_GROUP_BY jest ustawione na twoim lokalnym serwerze (MySQL 5.7).
Myślę, że popełniłeś błąd w opisie problemu. Powinieneś otrzymać błąd na lokalnym serwerze, ale nie na serwerze live, jeśli lokalny ma ONLY_FULL_GROUP_BY, a live nie.
Sugeruję, abyś używał tej samej wersji w rozwoju, co wersja, której używasz w produkcji, a także pasował do tego samego trybu SQL. Zapobiegnie to zamieszaniu podczas opracowywania.
To samo sugeruję odnośnie wersji PHP. Jeśli korzystasz z nowych funkcji PHP 7 w fazie rozwoju, a następnie wdrażasz je na swoim serwerze live PHP 5.6, nie będą one działać.
Opisany kod SQL powinien być w porządku:
select count(*) as aggregate from `parameter_log_site_detail` where `site_id` = EPE
To jest w porządku, nawet jeśli masz ONLY_FULL_GROUP_BY. Z pewnością legalne jest wykonanie select count(*) wszystkich pasujących wierszy w tabeli. Nie potrzebujesz klauzuli GROUP BY dla tego zapytania.
Jeśli jednak wymieszasz kolumny zagregowane z kolumnami niezagregowanymi, naruszysz wymagania ONLY_FULL_GROUP_BY, ponieważ kolumny niezagregowane byłyby niejednoznaczne.
select id, count(*) as aggregate from ...
Zastanawiam się, czy Laravel wstawia dodatkowe kolumny do listy wyboru przed przygotowaniem zapytania. Aby mieć pewność, musisz włączyć dziennik zapytań MySQL.
Zauważyłem, że istnieje dyskusja na temat tego błędu w kwestiach Laravel:https://github.com /laravel/framework/issues/15232
Rozwiązaniem, które kilku użytkowników w tym wątku stwierdziło, że naprawia ten problem, jest ustawienie 'strict'=>false w twoim Laravel config/database.php.
Ale założę się, że główną przyczyną jest to, że Laravel modyfikuje twoje zapytanie SQL.
