LEFT JOIN记录数变多是因为左表一行可匹配右表多行，属一对多场景；需先确认是否真需去重，再选择聚合、窗口函数或修正ON条件，而非盲目用DISTINCT。
为什么 LEFT JOIN 后记录数反而变多了？
这不是数据“变多”了，而是 LEFT JOIN 本身允许左表一行匹配右表多行——只要右表有多个满足条件的记录，左表那行就会被“撑开”成多行。常见于订单表关联订单项、用户表关联登录日志等一对多场景。
排查时别急着加 DISTINCT，先确认是否真要“去重”，还是该聚合（如统计数量、取最新时间）或限制右表匹配条数。
- 用
COUNT(*)和COUNT(DISTINCT left_id)对比，看膨胀倍数 - 对右表加
GROUP BY再JOIN，适合需要聚合结果的场景（如每个用户最近一次登录时间） - 用窗口函数在右表预处理，比如
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC)筛出每用户的首条记录，再JOIN
ON 条件写错导致隐式笛卡尔积
当 ON 子句漏掉关键关联字段，或用了恒真条件（如 ON 1=1），数据库会退化为交叉连接，记录数 = 左行数 × 右行数。这种错误在多表 JOIN 中极难肉眼发现，但执行计划里通常显示 Hash Join 或 Nested Loop 的 inner rows 异常巨大。
- 检查每个
ON是否至少包含一个明确的等值关联（如t1.id = t2.t1_id） - 避免在
ON里写IS NULL或模糊匹配（如LIKE），这不仅易引发重复，还大概率使索引失效 - 临时把
JOIN改成LEFT JOIN并加WHERE right_table.id IS NULL，可快速验证是否存在“无匹配却强行连接”的逻辑漏洞
如何安全地用 DISTINCT 去重而不掩盖问题？
DISTINCT 是最粗暴的去重手段，但它不解决根源——只是把重复行合并显示。如果业务上本该一对一却出现多对一，DISTINCT 会隐藏数据一致性缺陷，后续查问题更难。
- 只在确认语义正确且无需保留明细时用：
SELECT DISTINCT t1.id, t1.name FROM orders t1 LEFT JOIN order_items t2 ON t1.id = t2.order_id - 若字段来自右表（如
t2.item_name），DISTINCT会随机选一个值，不可控——此时必须改用GROUP BY显式指定聚合逻辑 - 注意
DISTINCT作用于整行，哪怕只差一个空格或大小写，也会被视为不同行；必要时先用TRIM()、UPPER()统一格式
用 EXISTS 替代 JOIN 避免重复的适用场景
当你只需要判断“左表某行在右表是否存在匹配”，而非获取右表字段，EXISTS 比 JOIN 更准确、更高效，且天然不产生重复。
- 替代写法：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM logins l WHERE l.user_id = u.id AND l.date >= '2024-01-01') - 和
IN的区别：当右表可能含NULL时，EXISTS行为稳定，IN会整体返回空结果 - 不能用
EXISTS获取右表字段，也不能做聚合；一旦需要右表内容，就得回到JOIN+ 明确去重策略
真正麻烦的不是语法，而是分不清“我要的是存在性判断”还是“我要的是关联后的明细”。很多重复问题，其实源于一开始没想清楚这个需求边界。
