join后出现重复行是关系模型一对多关联的自然行为，并非sql错误；应通过row_number()+子查询取代表值、exists判断存在性、先聚合再join等方式精准控制结果。
为什么JOIN后会出现重复行
不是SQL写错了，是关系模型本身在执行一对多关联时的自然行为。比如一个用户有3条登录日志，LEFT JOIN login_logs就会把该用户信息复制出3行——数据库没做错，只是你没告诉它“我只需要最新那条”。关键要区分：这是数据膨胀，不是脏数据。
用ROW_NUMBER() + 子查询精准取一条
适合需要从多条匹配记录中选代表值（如最新、最早、最高分）的场景。核心是先编号、再筛选，且rn = 1必须写在ON条件里，不能放WHERE。
-
PARTITION BY字段必须是主表关联键（如user_id），确保每组独立编号 -
ORDER BY字段要有业务意义且尽量唯一（如login_time DESC, id DESC），避免排序不稳定 - MySQL 5.7 及更早版本不支持窗口函数，得用自连接或变量模拟，别硬套
- 示例中若把
AND l.rn = 1挪到WHERE，LEFT JOIN就退化成INNER JOIN，没登录记录的用户直接消失
用EXISTS替代JOIN判断存在性
当你只关心“有没有匹配”，而不是“匹配了什么”，EXISTS比JOIN干净得多——不拼接、不膨胀、天然无重复。
-
SELECT *里不能出现右表字段，这是限制，不是缺陷 - 写
SELECT 1比SELECT *更明确，优化器也更容易跳过字段解析 - 多个存在性判断（如“有未发货订单”且“有已评价订单”）用并列
EXISTS，比JOIN安全，不会因某一方无匹配而丢主表数据 - 别在
EXISTS子查询里加ORDER BY或LIMIT，毫无意义还拖慢性能
先聚合再JOIN避免行数爆炸
要统计、汇总或带单值字段（如订单总数、最新登录时间），别把所有表一次性JOIN完再GROUP BY——中间结果可能膨胀几十倍。
- 对从表单独聚合（如
SELECT user_id, COUNT(*), MAX(login_time) FROM logins GROUP BY user_id），再和主表LEFT JOIN -
GROUP BY字段必须和JOIN条件一致，否则仍会重复；MySQL 5.7严格模式下，SELECT里的非分组字段必须用聚合函数包裹 - 如果要拼接多值（如用户所有车辆型号），用
GROUP_CONCAT()（MySQL）或STRING_AGG()（PostgreSQL），而不是靠DISTINCT硬去重 -
DISTINCT作用于整行，哪怕只有item_id不同，也算不同行——它解决不了“我要每个用户一行”的语义需求
DISTINCT或GROUP BY都只是掩盖问题。
