GROUP BY本身不会产生重复行，重复源于JOIN导致的数据膨胀；定位方法是用COUNT(*) OVER分析膨胀程度，再检查右表数据分布、JOIN条件与WHERE位置，并根据需求选择EXISTS、预聚合或窗口函数避免错误。
JOIN后GROUP BY还有重复行？先查膨胀点在哪
GROUP BY本身不会产生重复，它只是把已有行分组聚合。所谓“重复”，几乎全是JOIN阶段数据已膨胀导致的——比如users表1行，orders表里对应3行，LEFT JOIN后就是3行，再怎么GROUP BY users.id，结果仍是3行聚合值。
快速定位方法：
- 执行
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id，看cnt是否远超业务常识（如单用户订单数普遍>10） - 若异常，立刻查右表：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 5 - 检查
WHERE是否误写在JOIN之后却过滤右表字段（如WHERE o.status = 'paid'），应改到ON里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
要主表一行就一行？别硬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字段决定哪条被保留
聚合字段混用时，粒度错位比重复更危险
常见错误是把明细级字段和主表级字段混在同一个SELECT里共用GROUP BY，比如SELECT orders.id, SUM(orders.amount), SUM(order_items.quantity * order_items.price) FROM orders JOIN order_items ON orders.id = order_items.order_id GROUP BY orders.id。
问题在于：
-
orders.amount是主表单值，但JOIN后被重复计算（1订单×3明细→amount加3次） -
order_items.quantity * price是明细级度量，语义粒度和orders.id不匹配 - 真正安全的做法是：先在
order_items表内按order_id聚合出总金额，再和orders表关联
最容易被忽略的是：JOIN后的结果集已经不是原始主表的行集合，把它当唯一实体继续操作，错误就埋下了。
