GROUP BY后出现重复行实为JOIN阶段数据膨胀所致，需检查ON条件有效性、避免恒真条件、修正WHERE与ON位置、处理字段类型不一致，并用窗口函数或ROW_NUMBER()从源头控量。
GROUP BY后还有重复行？先查JOIN是否已膨胀
聚合结果里出现“重复”，大概率不是GROUP BY的问题，而是JOIN阶段已经把一行主表数据撑成多行了。比如用户表100行，订单日志表里同一个user_id有5条记录，LEFT JOIN后这用户就变成5行——再怎么GROUP BY user_id，结果也是5行聚合值，不是1行。
快速定位方法：
- 执行SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS cnt FROM users u LEFT JOIN login_logs l ON u.id = l.user_id，看cnt是否远超业务预期
- 若cnt异常高，立刻查右表：SELECT user_id, COUNT(*) FROM login_logs GROUP BY user_id HAVING COUNT(*) > 1
- 同时检查WHERE是否误写在JOIN之后却过滤右表字段（如WHERE l.status = 'active'），应改到ON条件里：LEFT JOIN login_logs l ON u.id = l.user_id AND l.status = 'active'
只想要主表一行？别硬JOIN，改用EXISTS或子查询
当业务只要“有没有关联记录”或“某个汇总值”，却因一对多JOIN导致重复，强行加DISTINCT或外层GROUP BY既慢又不可靠——整行字段稍有差异就去不掉。
更干净的做法：
- 判断存在性：用EXISTS代替LEFT JOIN，例如SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
- 取单个汇总值：右表预聚合，如SELECT u.*, p.last_login FROM users u LEFT JOIN (SELECT user_id, MAX(created_at) AS last_login FROM login_logs GROUP BY user_id) p ON u.id = p.user_id
- 注意：子查询里的GROUP BY字段必须和JOIN条件一致，否则仍会膨胀
要保留右表完整字段？窗口函数比DISTINCT靠谱
DISTINCT对整行去重，但你常需要的是“每个用户最新一条订单的全部字段”，这时DISTINCT完全无效——它无法指定“最新”逻辑，也无法保证order_status和amount来自同一行。
正确姿势：
- 用ROW_NUMBER()标记每组内的顺序：SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders
- 外层筛出首行：SELECT user_id, order_no, amount, status FROM (上述子查询) t WHERE rn = 1
- MySQL 5.7不支持窗口函数，得用自连接或变量模拟；PostgreSQL/SQL Server/MySQL 8.0+可直接用
- 切记：PARTITION BY字段必须和业务分组维度一致，ORDER BY字段决定哪条被保留
GROUP BY报错或结果不准？检查非分组字段是否合规
MySQL 5.7+开启ONLY_FULL_GROUP_BY后，SELECT id, name, COUNT(*) FROM orders GROUP BY user_id会直接报错——因为id和name既没出现在GROUP BY里，也没套聚合函数。
解决方式取决于你要什么：
- 只需分组键和统计值：删掉多余字段，写成SELECT user_id, COUNT(*) FROM orders GROUP BY user_id
- 需要某条代表记录的字段（如最早下单时间）：用MIN(created_at)或MAX(created_at)包裹
- 需要某行完整内容：回到窗口函数方案，ROW_NUMBER()才是源头可控的方式
- 数据本身有完全重复行（所有字段都一样）：可在子查询里先SELECT DISTINCT再GROUP BY，但这种情况较少见，优先查ETL或写入逻辑是否出错
重复行问题从来不在聚合语法本身，而在数据关联路径是否干净、业务意图是否被准确翻译成SQL语义。最危险的不是查不出重复，而是用DISTINCT或外层GROUP BY掩盖了JOIN膨胀，让COUNT和SUM悄悄虚高。
