JOIN产生重复行是因笛卡尔积式匹配，一对多关系未聚合或去重、ON条件宽松/缺失、多表JOIN遗漏条件均会触发；验证需按主键GROUP BY查COUNT(*)最大值，收敛依需求选EXISTS、预聚合或DISTINCT。
JOIN 产生重复行是因为笛卡尔积式匹配
当左表某行与右表多行满足 ON 条件时，SQL 就会为该左行生成多条组合结果——这不是 bug，而是 JOIN 的语义本身。比如用户表一条记录关联订单表 3 条订单，LEFT JOIN 后就会出现 3 行相同用户信息。
常见触发场景：一对多关系未加聚合或去重
最典型的是「主表单条记录 + 明细表多条记录」结构，例如：orders 关联 order_items，或 users 关联 user_tags。只要没对明细侧做 GROUP BY、STRING_AGG 或 DISTINCT 处理，重复就必然发生。
- 用
COUNT(*)统计前没GROUP BY主键 → 数值虚高 - 直接
SELECT *查带 JOIN 的报表 → 表格行数膨胀 - 把 JOIN 结果当唯一主表用（如后续再 JOIN 其他表）→ 错误级联放大
ON 条件宽松或缺失导致隐式交叉连接
ON 子句写错、漏写、或用了恒真条件（如 ON 1=1），会让 JOIN 退化成 CROSS JOIN，结果行数 = 左行数 × 右行数。哪怕只有一张小表（10 行）和一张中等表（1000 行），也会生成 10,000 行。
- 忘记写
ON条件（某些方言允许，但结果危险） -
ON中用了非主键/非唯一列（如仅靠status = 'active'匹配） - JOIN 多张表时，某次 ON 条件意外遗漏，连带影响整条链
如何验证和控制重复：从诊断到收敛
先确认是否真有重复：对 JOIN 后的结果按主表主键 GROUP BY，查 COUNT(*) 最大值；若 >1，说明存在一对多未处理。收敛方式取决于需求：
- 只需要主表一行 → 改用
EXISTS或LATERAL（PostgreSQL）/APPLY（SQL Server）替代 JOIN - 需要汇总信息（如订单总金额）→ 对明细表先
GROUP BY再 JOIN，或用子查询聚合 - 需要展开但去重显示 → 在外层用
DISTINCT ON (user_id)（PostgreSQL）或窗口函数ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ...)
真正容易被忽略的是：JOIN 本身的重复是“合法且预期”的，问题往往出在后续没意识到它已不是原始主表的行集合。一旦把它当唯一实体继续操作，错误就埋下了。
