Възможно е да зададете SQL режим ONLY_FULL_GROUP_BY в MySQL 5.6, но не е зададен по подразбиране (вижте https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html ).
Аха, виждам, че коментарът ви се появи по-горе, потвърдихте, че ONLY_FULL_GROUP_BY е зададен на вашия локален сървър (MySQL 5.7).
Мисля, че сте объркали нещо в описанието на проблема си. Трябва да получите грешката на вашия локален сървър, но не и на живия сървър, ако локалният има ONLY_FULL_GROUP_BY, а живият не.
Предлагам ви да се уверите, че използвате същата версия в разработката като версията, която използвате в производството, и също така да съответства на същия SQL режим. Това ще предотврати объркване по време на разработката.
Правя същото предложение за версията на PHP. Ако използвате някои нови функции на PHP 7 в разработката и след това внедрите на вашия PHP 5.6 жив сървър, те няма да работят.
SQL, който описвате, трябва да е наред:
select count(*) as aggregate from `parameter_log_site_detail` where `site_id` = EPE
Това всъщност е добре, дори ако имате ONLY_FULL_GROUP_BY. Със сигурност е законно да направите select count(*) от всички съвпадащи редове в таблицата. Не се нуждаете от клауза GROUP BY за тази заявка.
Но ако смесите агрегирани колони с неагрегирани колони, ще нарушите изискванията на ONLY_FULL_GROUP_BY, тъй като необобщените колони биха били двусмислени.
select id, count(*) as aggregate from ...
Чудя се дали Laravel вмъква допълнителни колони във вашия списък за избор, преди да подготви заявката. Трябва да активирате регистъра на заявките на MySQL, за да сте сигурни.
Забелязвам, че има известно обсъждане на тази грешка относно проблеми с Laravel:https://github.com /laravel/framework/issues/15232
Решението, според което няколко потребители в тази тема решават проблема, е да зададете 'strict'=>false във вашия Laravel config/database.php.
Но бих се обзаложил, че основната причина е, че Laravel променя вашата SQL заявка.
