INNER JOIN重复是语义必然，不是数据出错：它按笛卡尔积逻辑匹配，左表一行匹配右表多行即生成多行；重复根源在于连接键缺乏唯一性，须在JOIN前通过聚合、窗口函数或EXISTS收敛右表。
INNER JOIN重复是语义必然，不是数据出错
INNER JOIN产生重复行，是因为它严格按笛卡尔积逻辑匹配：左表某行只要和右表多行满足ON条件，就会生成多条结果。比如users表中id = 101的用户，在orders表里有3条订单记录，那SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.id = o.user_id就会输出3行，u.name重复出现3次——这不是Bug，是SQL标准行为。
常见误判点：
- 以为“只选左表字段”就能避免重复 → 实际上JOIN在
SELECT投影前就完成了行组合 - 看到重复就加
DISTINCT→ 若右表字段含log_time、amount等差异列，DISTINCT根本无效 - 把膨胀后的结果当主表继续
JOIN→ 错误会级联放大，后续统计全失真
查ON条件是否真能保证一对一
重复根源几乎总在连接键的唯一性缺失。必须验证：ON字段在右表是否真的具备业务唯一性？例如用user_id关联订单表，但orders.user_id没有UNIQUE约束或索引，就注定重复。
快速诊断方法：
- 执行
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5，看头部是否有>1的计数 - 检查
EXPLAIN结果里是否出现type: ALL或rows异常高，可能暗示隐式全表扫描（如users.id是INT，orders.user_id却是VARCHAR） - 确认
ON子句没漏写、没写成恒真条件（如ON 1=1），否则退化为CROSS JOIN
别在JOIN后去重，要在JOIN前收敛右表
DISTINCT是最后手段，且代价高、不可控。真正高效的做法，是在右表参与JOIN前就把它“压成一行”。
根据需求选方案：
- 只需要汇总值（如最新登录IP、订单总数）→ 用子查询+
GROUP BY预聚合：SELECT u.id, u.name, p.max_ip<br>FROM users u<br>LEFT JOIN (SELECT user_id, MAX(ip_addr) AS max_ip FROM t_log GROUP BY user_id) p<br> ON p.user_id = u.id
- 需要某一条完整明细（如最新一条日志）→ 用窗口函数+
rn = 1放在ON里：SELECT u.id, u.name, p.ip_addr, p.log_time<br>FROM users u<br>LEFT JOIN (<br> SELECT user_id, ip_addr, log_time,<br> ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn<br> FROM t_log<br>) p ON p.user_id = u.id AND p.rn = 1
注意：p.rn = 1必须写在ON，不能放WHERE，否则丢失无日志的用户 - 只判断“是否存在” → 直接改用
EXISTS：SELECT u.* FROM users u<br>WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id)
语义清晰、不引入重复、还能提前终止扫描
分页时JOIN重复会直接导致数据错乱
带LIMIT/OFFSET的JOIN查询极易因重复行触发分页偏移错位。典型现象：同一条订单在LIMIT 1350, 50和LIMIT 1400, 50里各出现一次——因为排序字段（如i.d_no）在重复行中相同，数据库无法稳定确定行序。
关键规避点：
- 分页前务必确保结果集每行逻辑唯一，至少加一个确定性排序字段（如
o.id或o.create_time） - 避免对JOIN结果直接分页；优先在子查询里先去重/聚合，再对外层结果分页
- 若必须分页明细，排序字段应包含右表主键（如
ORDER BY o.id, i.id），防止相同o.id下i行顺序不可控
最常被忽略的一点：JOIN产生的重复行本身不可怕，可怕的是你把它当成“原始主表的行集合”继续计算、导出或分页——那一刻，问题才真正开始蔓延。
