Det är möjligt att ställa in SQL-läge ONLY_FULL_GROUP_BY i MySQL 5.6, men det är inte inställt som standard (se https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html ).
Aha, jag ser att din kommentar dök upp ovan, du har bekräftat att ONLY_FULL_GROUP_BY är inställd på din lokala server (MySQL 5.7).
Jag tycker att du har feltolkat något i din problembeskrivning. Du bör få felet på din lokala server, men inte på liveservern, om local har ONLY_FULL_GROUP_BY och live inte har det.
Jag föreslår att du ser till att använda samma version i utvecklingen som den version du använder i produktionen, och även matcha samma SQL-läge. Detta kommer att förhindra förvirring under utvecklingen.
Jag ger samma förslag om version av PHP. Om du använder några nya PHP 7-funktioner under utveckling och sedan distribuerar till din PHP 5.6 live-server, kommer de inte att fungera.
Den SQL du beskriver borde vara bra:
select count(*) as aggregate from `parameter_log_site_detail` where `site_id` = EPE
Det här är faktiskt okej, även om du har ONLY_FULL_GROUP_BY. Det är verkligen lagligt att göra en select count(*) av alla matchande rader i tabellen. Du behöver inte en GROUP BY-sats för den här frågan.
Men om du blandar aggregerade kolumner med icke aggregerade kolumner skulle du bryta mot ONLY_FULL_GROUP_BY-kraven, eftersom de icke aggregerade kolumnerna skulle vara tvetydiga.
select id, count(*) as aggregate from ...
Jag undrar om Laravel infogar extra kolumn(er) i din urvalslista innan frågan förbereds. Du måste aktivera MySQL-frågeloggen för att vara säker.
Jag märker att det finns en diskussion om detta fel om Laravel-problem:https://github.com /laravel/framework/issues/15232
Lösningen som flera användare i den tråden sa åtgärdar problemet är att ställa in 'strict'=>false i din Laravel config/database.php.
Men jag skulle slå vad om att grundorsaken är att Laravel ändrar din SQL-fråga.