group by本身不产生重复行，重复源于join导致的行数膨胀；需通过count(*)验证膨胀、将右表过滤条件移至on子句、用预聚合或row_number()控制关联粒度。
GROUP BY 本身不会产生重复行，出现重复行说明数据在 GROUP BY 执行前就已经膨胀了——根本问题出在 JOIN 阶段。
JOIN 导致行数爆炸，GROUP BY 只是“照单全收”
比如 users 表 1 行，orders 表有该用户 3 条订单，LEFT JOIN 后就变成 3 行；再 GROUP BY user_id，结果仍是 3 行（每行都带相同的 user_id，但聚合值来自不同订单）。这不是 GROUP BY 的错，是 JOIN 先把它撑开了。
- 快速验证：执行
SELECT u.id, COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id，看最大COUNT(*)是否远超业务合理值（如一个用户不该有 500 条订单） - 若某
u.id对应的COUNT(*)异常高，直接查右表：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5 - 注意
ON条件是否恒真（如漏写条件、或写成ON 1=1），这会让 JOIN 退化为 CROSS JOIN
WHERE 写错位置，把过滤逻辑丢给了 GROUP BY
常见错误是把本该限制右表的条件写在 WHERE 里，例如 WHERE o.status = 'paid'。这会导致先 JOIN（可能已膨胀），再过滤——左表被连带“拖垮”。正确做法是把右表过滤条件塞进 ON 子句：
- 错：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'→ 实际变成INNER JOIN，且左表空用户被剔除 - 对：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'→ 保留所有用户，只关联已支付订单 - 特别注意 NULL：如果
o.status允许为 NULL，AND o.status = 'paid'不会匹配 NULL 行，符合预期
GROUP BY 字段没覆盖语义主键，导致“分组过细”
你本想按用户统计，但 SELECT 里带了 order_status，又只写 GROUP BY user_id，MySQL 8.0+ 严格模式下直接报错；妥协写成 GROUP BY user_id, order_status，结果就按“用户+状态”分组，自然出现多行。
- 检查
SELECT中每个非聚合字段是否都在GROUP BY列表里，或明确套了MAX()/MIN()/ANY_VALUE() - 如果真要取“每个用户的最新订单完整记录”，别硬凑
GROUP BY，改用ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)标记后筛rn = 1 - 子查询中用了
GROUP BY却仍返回重复user_id？确认GROUP BY字段和外层JOIN键完全一致，避免GROUP BY user_id, status却只拿user_id去关联
DISTINCT 或外层 GROUP BY 是掩盖，不是解决
看到重复就加 DISTINCT 或在外层再套一层 GROUP BY，看似行得通，实则危险：
-
DISTINCT对整行去重，但你真正需要的可能是“每个用户最新一条订单的全部字段”，而DISTINCT无法保证这些字段来自同一行 - 外层
GROUP BY会强制触发聚合，若漏写字段或用错函数，结果不可靠，且性能更差 - 真正要的是源头控量：要么用
EXISTS判断存在性，要么用子查询预聚合（如(SELECT MAX(created_at) FROM orders WHERE user_id = u.id)），要么用窗口函数精准取首行
最容易被忽略的一点：JOIN 后的数据集已经不是原始主表的行集合了。一旦你把它当作“唯一用户列表”继续和其他表 JOIN，重复就会指数级放大。诊断必须从 JOIN 后立刻按主键 GROUP BY 看 COUNT(*) 分布，而不是等最后结果出来再回头猜。
