Wykonujesz group by (3 kolumny) z 5 kolumnami niezagregowanych kolumn na liście wyboru. Ponadto, nie ma to znaczenia, w wyniku kolumny nie ma agregatów.
MySQL traktuje to jako distinct (dla 3 kolumn) i przywraca pierwszy wiersz napotkany w pamięci podręcznej MRU, a jeśli nie ma pamięci podręcznej, pierwsze napotkane w indeksie klastrowym lub kolejności fizycznej, aby spełnić 2 kolumny niezgrupowane według.
Innymi słowy, jest to błąd użytkownika. Snafu. Zalecam uporządkowanie intencji za pomocą GROUP BY .
Trochę powiązane, przeczytaj moją ostatnią odpowiedź Tutaj
związane z ONLY_FULL_GROUP_BY . Zobacz na dole tego linku Obsługa MySQL GRUPUJ WG
co moim zdaniem jest odzwierciedleniem rzeczywistych problemów i niestandardowych standardów, na które pozwalał MySQL, co powodowało nieoczekiwane i trudne do wyjaśnienia dane wynikające z naruszeń tego standardu.
Co więc zrobił zespół programistów MySQL? Domyślnie zaimplementowali standard (począwszy od wersji 5.7), aby uniemożliwić typy zapytań, które właśnie wykonałeś.
Edytuj1
Twoje zapytanie bez GROUP BY ale z order by newGroups.id,people.id , na serwerze w wersji 5.7.14:
