inner join后直接group by会产生重复行，因一对多连接使主表一行膨胀为多行，group by仅分组不解决源头膨胀；须在join前用子查询或窗口函数收敛右表。
INNER JOIN后直接用GROUP BY会多出重复行？
很多人写完 INNER JOIN 紧接着加 GROUP BY，结果发现行数比预期多，甚至翻倍。这不是语法错误，而是连接本身引入了一对多关系：比如一个客户有 3 笔订单，JOIN 后这客户信息就会出现 3 次，再 GROUP BY customer_id 虽然能归并，但若 SELECT 中漏了聚合约束，MySQL（尤其旧版本）可能随机返回某条订单的非分组字段值，SQL Server 则直接报错。
关键判断点：先确认 JOIN 后是否存在一对多。查一下连接字段的分布：
SELECT o.customer_id, COUNT(*) cnt FROM orders o GROUP BY o.customer_id HAVING COUNT(*) > 1;
如果返回结果不为空，说明必须处理“一对多”带来的冗余，不能靠 GROUP BY 硬压。
用子查询先去重，再JOIN更安全
真正可控的写法是把去重逻辑提前到子查询里，避免在连接后“补救”。例如：要取每个客户的最新一笔订单信息（含订单详情），不要写：
SELECT c.name, o.order_date, o.amount FROM customers c INNER JOIN orders o ON c.id = o.customer_id GROUP BY c.id, c.name;
而应该先用子查询锁定每个客户的“代表订单”：
-
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC)（SQL Server / MySQL 8.0+） - 或
MAX(order_date)+ 再关联一次（兼容老版本）
推荐写法（带完整字段）：
SELECT c.name, o.order_date, o.amount
FROM customers c
INNER JOIN (
SELECT customer_id, order_date, amount,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date DESC) AS rn
FROM orders
) o ON c.id = o.customer_id AND o.rn = 1;
这样既保留了客户和订单的完整字段，又确保每个客户只出现一次，且选的是最新订单。
GROUP BY列必须覆盖所有非聚合字段
SQL Server 和较新 MySQL 严格要求：SELECT 列表中所有未用聚合函数包裹的字段，都必须出现在 GROUP BY 子句中。否则报错 Column 'xxx' is invalid in the select list。
常见错误写法：
SELECT c.name, o.order_date, COUNT(*) FROM customers c INNER JOIN orders o ON c.id = o.customer_id GROUP BY c.id; -- ❌ 缺少 c.name 和 o.order_date
正确做法只有两个选择：
- 把所有非聚合字段加进
GROUP BY（如GROUP BY c.id, c.name, o.order_date）——但这就失去了“去重”意义，因为订单日期不同仍会拆成多行 - 改用聚合函数包裹非分组字段，例如
MAX(o.order_date)、STRING_AGG(o.status, ',')（SQL Server 2017+）或GROUP_CONCAT()（MySQL）
所以，真想“按客户去重并取某笔订单”，别指望 GROUP BY 自动挑数据——它不负责选哪条，只负责分组后计算。
DISTINCT vs GROUP BY：什么时候该换思路
如果目标只是“查出不重复的客户+订单组合”，且不需要统计或取特定记录，DISTINCT 更轻量：
SELECT DISTINCT c.name, o.order_id FROM customers c INNER JOIN orders o ON c.id = o.customer_id;
但注意：DISTINCT 是对整行去重，只要任意一列值不同，就算不同行；而 GROUP BY 是逻辑分组，适合后续聚合。两者语义不同，不能无脑互换。
容易被忽略的一点：当 JOIN 后字段较多、其中某些字段存在 NULL 值时，DISTINCT 和 GROUP BY 对 NULL 的处理一致（视为相同），但窗口函数如 ROW_NUMBER() 默认把 NULL 排在最前/最后，取决于 ORDER BY 是否加 NULLS LAST（部分数据库支持）。这点在按时间字段排序取“最新”时，可能让 NULL 订单意外胜出。
