Vous effectuez un group by (3 colonnes) avec 5 colonnes de colonnes non agrégées dans la liste de sélection. De plus, peu importe, il n'y a pas d'agrégats dans la sortie de la colonne.
MySQL traite cela comme un distinct (pour les 3 colonnes) et ramène la première ligne rencontrée dans le cache MRU, et s'il n'y a pas de cache, les premières rencontrées dans l'index clusterisé ou l'ordre physique pour satisfaire les 2 colonnes non groupées par.
En d'autres termes, il s'agit d'une erreur de l'utilisateur. Un snafu. Je recommande de nettoyer votre intention avec le GROUP BY .
Quelque peu lié, lisez une de mes réponses récentes Ici
lié à ONLY_FULL_GROUP_BY . Voir au bas de ce lien est MySQL Handling of GROUPER PAR
ce qui, à mon avis, est une explication des vrais problèmes et des non-standards que MySQL a autorisés, ce qui a rendu des données inattendues et difficiles à expliquer à partir de violations de ce standard.
Alors, qu'a fait l'équipe de développement de MySQL ? Ils ont implémenté la norme par défaut (à partir de la version 5.7) pour interdire les types de requêtes que vous venez d'effectuer.
Modifier1
Votre requête, sans GROUP BY mais avec un order by newGroups.id,people.id , sur un serveur version 5.7.14 :
