left join后行数翻倍是正常现象，因右表一对多导致左表行被复制；应通过预聚合、窗口函数或exists控制右表粒度，而非依赖distinct或where过滤。
为什么LEFT JOIN后行数突然翻倍？
这不是SQL出错，是JOIN在严格执行关系代数：只要右表对同一个连接键（比如user_id）有N条记录，左表那行就会被复制N次。比如用户表100行，日志表里某个user_id出现5次，结果就多出4行重复——这5行共享同一用户信息，但log_time、ip各不相同。
常见误判信号：COUNT(*)远大于左表原始行数；加了DISTINCT但一选右表字段，重复立刻回来；后续再JOIN第三张表，膨胀级联放大。
- 先用
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS cnt看每条主表记录被撑开几次，cnt > 1即确认一对多存在 - 别急着加
DISTINCT或外层GROUP BY，它们只是“擦除”，不解决源头膨胀 - 检查右表是否缺少
UNIQUE(user_id)或PRIMARY KEY约束——没这个，重复就是逻辑必然
ON里漏条件 or 写错位置，会触发隐式笛卡尔积
当ON子句漏掉关键等值关联（如只写l.status = 'active'却没写u.id = l.user_id），或者用了恒真条件（如ON 1=1），JOIN就退化成CROSS JOIN，结果行数 = 左行数 × 右行数。10行 × 1000行 = 1万行，查不出错，但执行计划里Nested Loop的inner rows会异常巨大。
- 每个
ON必须至少包含一个明确的等值关联，如t1.id = t2.t1_id -
WHERE里的右表过滤条件（如l.status = 'active'）必须挪到ON里，否则LEFT JOIN会退化为INNER JOIN，NULL行直接消失 - 避免在
ON中用IS NULL、LIKE等非SARGable表达式，大概率使索引失效，还易引发意外匹配
用ROW_NUMBER()筛出每组首行，但ON里必须带rn = 1
要保留右表完整字段（比如最新一条订单的所有列），ROW_NUMBER()比DISTINCT或GROUP BY精准得多——它不丢字段，也不随机选值。但关键细节常被忽略：rn = 1必须写在ON条件里，不能放WHERE。
- 正确写法：
LEFT JOIN (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn FROM login_logs) l ON u.id = l.user_id AND l.rn = 1 - 错误写法：
LEFT JOIN (...) l ON u.id = l.user_id WHERE l.rn = 1→WHERE会过滤掉所有l.rn IS NULL的行，LEFT JOIN实效等同INNER JOIN -
ORDER BY字段必须有索引；若存在时间相同的情况（如秒级精度），补二级排序字段，如ORDER BY log_time DESC, id DESC，否则每次执行结果可能不同
MySQL 5.7不支持窗口函数，替代方案很脆弱
ROW_NUMBER()在MySQL 8.0+、PostgreSQL、SQL Server都原生支持，但MySQL 5.7会直接报错：ERROR 1064: This version of MySQL doesn't yet support 'OVER'。此时有人用自连接模拟，但极易出错。
- 典型自连接写法：
LEFT JOIN login_logs l2 ON u.id = l2.user_id AND l2.log_time > l.log_time WHERE l2.user_id IS NULL - 问题：性能差（O(n²)），无法处理
log_time完全相同的情况，且l2.user_id IS NULL在NULL值存在时逻辑不可靠 - 更稳妥的路径是升级MySQL到8.0+；若无法升级，优先用子查询预聚合（如
MAX(log_time)+ 再关联一次），虽多一次JOIN，但语义清晰、可预测
