The insane ability to allow partial group by in older versions of MySQL, has to be one top contender for most caused confusion in the it industry.
Given the table:
CREATE TABLE t
( x int not null primary key
, y int not null
);
INSERT INTO t (x,y) VALUES (1,1),(1,2);
The statement
SELECT x, y FROM t GROUP BY x
could mean (1,1) or (1,2) and MySQL would randomly return one of these. DISTINCT does not matter in this case, the result is still in-deterministic.
SQL92 required that all columns in the select clause (except aggregated columns, and constants) is part of the GROUP BY clause.
SQL99 loosened this restriction a bit and allowed us to leave out columns from the GROUP BY that are functionally dependent of the remaining columns. I.e.
CREATE TABLE t
( x int not null primary key
, y int not null
);
SELECT x, y FROM t GROUP by x
would be valid since y is f.d. of x
Surprisingly enough (for me) later version of MySQL is best in class when it comes to implement the SQL99 version. I haven't checked it lately, but when I did MySQL handled fairly complicated scenarios well, where as PostgreSQL only handled trivial ones.
To answer your questions
1)
SELECT x, y FROM t GROUP BY x, y
means that the combination of x, y is a group. In all possible situations I can think of this is the same as:
SELECT DISTINCT x, y FROM t
Since they are logically evaluated at different times, there might be some corner-case where they would actually differ (I cant think of one though)
2) None, in this regard they are a set of columns, so there is no order
3) See above.
4) The logical order of evaluation of an SQL query is:
FROM, JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
FETCH FIRST
so GROUP BY is supposed to be evaluated before DISTINCT. I can not think of a situation where this would matter.
In your query I suspect that someone got confusing results, and tried to get another result using DISTINCT. They probably where lucky (or unlucky) to get the result they expected, so the DISTINCT stayed. The bug is still there though
GROUP BY
matters not at all (except that in old versions, it implied the sameORDER BY
. TheSELECT
order matters only in the arrangement of columns in the output.