Det er muligt at indstille SQL-tilstand ONLY_FULL_GROUP_BY i MySQL 5.6, men det er ikke indstillet som standard (se https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html ).
Aha, jeg kan se, at din kommentar dukkede op ovenfor, du har bekræftet, at ONLY_FULL_GROUP_BY er indstillet på din lokale server (MySQL 5.7).
Jeg synes, du har misforstået noget i din problembeskrivelse. Du skulle få fejlen på din lokale server, men ikke på live-serveren, hvis local har ONLY_FULL_GROUP_BY og live ikke har.
Jeg foreslår, at du sørger for at bruge den samme version i udviklingen som den version, du bruger i produktionen, og også matcher den samme SQL-tilstand. Dette vil forhindre forvirring under udviklingen.
Jeg kommer med det samme forslag om version af PHP. Hvis du bruger nogle nye PHP 7-funktioner under udvikling og derefter implementerer til din PHP 5.6 live-server, vil de ikke fungere.
Den SQL, du beskriver, burde være i orden:
select count(*) as aggregate from `parameter_log_site_detail` where `site_id` = EPE
Dette er faktisk okay, selvom du har ONLY_FULL_GROUP_BY. Det er bestemt lovligt at foretage en select count(*) af alle matchende rækker i tabellen. Du behøver ikke en GROUP BY-sætning til denne forespørgsel.
Men hvis du blander aggregerede kolonner med ikke-aggregerede kolonner, ville du overtræde ONLY_FULL_GROUP_BY-kravene, fordi de ikke-aggregerede kolonner ville være tvetydige.
select id, count(*) as aggregate from ...
Jeg spekulerer på, om Laravel indsætter ekstra kolonne(r) i din valgliste, før den forbereder forespørgslen. Du skal aktivere MySQL-forespørgselsloggen for at være sikker.
Jeg bemærker, at der er nogen diskussion om denne fejl om Laravel-problemer:https://github.com /laravel/framework/issues/15232
Løsningen, som flere brugere i den tråd sagde løser problemet, er at indstille 'strict'=>false i din Laravel config/database.php.
Men jeg vil vædde på, at grundårsagen er, at Laravel ændrer din SQL-forespørgsel.