left join 行数膨胀是其定义所致，并非sql错误；重复源于左表每行匹配右表所有满足on条件的行，需通过子查询聚合或窗口函数预处理右表来解决。
LEFT JOIN 重复是关系代数的自然结果，不是SQL写错了
当你看到 users 表 100 行，LEFT JOIN login_log 后变成 327 行，这不是 bug，而是 LEFT JOIN 的定义本身：左表每行，匹配右表所有满足 ON 条件的行。如果一个 user_id 在日志表里有 3 条记录，那用户信息就必然出现 3 次。
常见误判点包括：
- 用
COUNT(*)直接统计 JOIN 结果，当成“用户数”，结果虚高 - 后续再 JOIN 第三张表时，拿膨胀后的结果当主表，错误级联放大
- 看到重复就加
DISTINCT，但没意识到它只对最终字段组合去重，不解决逻辑膨胀
为什么 DISTINCT 对右表多值场景基本无效
DISTINCT 是对 SELECT 列表中所有字段的**组合值**去重。只要任意一列不同，整行就不算重复。比如你查 u.id, u.name, l.ip_addr, l.log_time，哪怕同一个用户有 5 条日志，l.ip_addr 或 l.log_time 都不同，DISTINCT 就不会合并任何一行。
更危险的是这种写法：
SELECT DISTINCT u.id, u.name FROM users u LEFT JOIN t_log l ON u.id = l.user_id
它看似“去重了”，但实际丢失了所有日志字段；而一旦你加上 l.ip_addr，重复立刻回来。这不是 DISTINCT 不好，而是它根本没在解决“一对多导致行膨胀”这个源头问题。
真正有效的解法：让右表先变“一行一主键”再 JOIN
核心思路只有一个：别让右表带着多条记录直接上场。必须先压缩它，再 JOIN。两种主流方式适用不同场景：
- 需要汇总值（如最新 IP、登录次数）→ 用
GROUP BY子查询：SELECT u.id, u.name, p.max_ip, p.cnt<br>FROM users u<br>LEFT JOIN (<br> SELECT user_id, MAX(ip_addr) AS max_ip, COUNT(*) AS cnt<br> FROM t_log GROUP BY user_id<br>) p ON p.user_id = u.id
- 需要完整单条记录（如最新一条日志全部字段）→ 用
ROW_NUMBER()窗口函数：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
注意：AND p.rn = 1必须写在ON子句里，不能放WHERE，否则会把没日志的用户也过滤掉。
容易被忽略的关键细节
最常被跳过的一步，是没确认右表连接键是否真有业务唯一性约束。比如 t_log(user_id) 缺少 UNIQUE 或 PRIMARY KEY，那重复就不是“能不能去”的问题，而是“该不该存在”的数据一致性问题。
另外，ON 条件写错也会伪装成“合理重复”：漏掉关键字段、用 LIKE 或 IS NULL 匹配、甚至恒真条件（如 ON 1=1），都可能让 JOIN 退化为交叉连接——这时候膨胀倍数不是几倍，而是左行数 × 右行数，排查时得看执行计划里的 inner rows 是否异常巨大。
