join结果重复不是bug，而是关系代数的必然表现；left join行数暴增源于左表1行匹配右表n行的语义本身，如1用户5订单则用户信息重复5次；distinct仅对整行去重，无法解决逻辑膨胀，应据业务需求选择exists、预聚合或row_number()精准控制。
JOIN 查询结果重复不是 bug，而是关系代数的必然表现；直接加 DISTINCT 往往治标不治本，甚至掩盖数据模型或逻辑缺陷。
为什么 LEFT JOIN 后行数暴增却不算错
左表 1 行匹配右表 N 行，结果就是 N 行——这是 LEFT JOIN 的语义本身。比如用户表关联订单表，一个用户有 5 笔订单，那用户字段就会重复出现 5 次。
- 用
COUNT(*)统计这个结果，会把“1 个用户 × 5 笔订单”算成 5 条记录，导致总数、平均值等全部失真 -
DISTINCT对整行生效：只要任意一列（如order_id、created_at）不同，就不会合并 - 若后续再
JOIN第三张表，这个膨胀结果会级联放大，错误雪球越滚越大
该去重还是该聚合？先分清你要什么
盲目去重前，必须明确业务目标：
- 只关心“用户是否存在订单” → 改用
EXISTS，天然无重复：SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) - 要统计每个用户的订单数、总金额 → 必须先对订单表
GROUP BY user_id，再JOIN，不能在膨胀后硬算COUNT(*) - 要取每个用户的最新一笔订单详情 → 窗口函数是唯一可靠方案：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，再筛rn = 1
用 ROW_NUMBER() 在 JOIN 前精准截断右表
这是处理“一对多中取一条”的黄金做法，但必须注意写法细节：
- 窗口函数必须放在 CTE 或派生表里，不能直接嵌套进
ON子句 -
rn = 1要写在ON条件中（如ON u.id = o.user_id AND o.rn = 1），写在WHERE会把没订单的用户全过滤掉（变相变成INNER JOIN） - 排序字段决定留哪条：
ORDER BY id ASC留最早插入的，ORDER BY updated_at DESC留最新更新的，漏写或写反会导致随机保留
WITH latest_order AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders ) SELECT u.name, o.amount, o.created_at FROM users u LEFT JOIN latest_order o ON u.id = o.user_id AND o.rn = 1;
DISTINCT 和 GROUP BY 到底怎么选
两者行为差异极大，不能互换：
-
DISTINCT是对最终结果集做整行去重，不改变语义，但不可控——右表字段（如item_name）若有多个值，DISTINCT会随机选一个展示 -
GROUP BY强制你声明聚合逻辑：SELECT u.id, u.name, COUNT(o.id), MAX(o.amount)，所有非分组字段必须包裹在聚合函数里，否则 MySQL 5.7+ 会报错 - 大数据量时，
GROUP BY若有索引（如INDEX(user_id, created_at)）通常比全量DISTINCT更快
真正容易被忽略的是：JOIN 后的“重复”，往往暴露的是业务建模问题——比如订单项表缺唯一约束、日志表未清理历史脏数据、或本该用外键强制一对一却放任了一对多。先查 SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1，比急着加 DISTINCT 有用得多。
