join后结果行数比左表多是正常行为，因右表对同一连接键存在多条记录时会复制左表对应行；需通过预聚合、窗口函数或exists等控制右表粒度，而非依赖distinct事后去重。

为什么JOIN后结果行数比左表多？

这是JOIN的正常行为，不是SQL出错。只要右表对同一个连接键（比如user_id）有多条记录，左表那行就会被复制多次——数据库严格按语义执行，不是bug，但后续统计或导出时容易误算。

常见现象：users表100行，t_log表里某个user_id出现7次，JOIN后这条用户就占7行。用COUNT(*)查JOIN结果，再对比左表原始行数，能快速确认膨胀倍数。

• 执行SELECT u.id, COUNT(*) OVER (PARTITION BY u.id)看每条用户被展开几次，>1就说明右表存在一对多
• 别只信COUNT(*)，加LIMIT 10并SELECT *看原始连接结果更可靠
• 后续再JOIN第三张表时，拿这个已膨胀的结果当主表，错误会级联放大

为什么加了DISTINCT还是有重复？

DISTINCT去重的是整行，不是单列。只要任意一列值不同（比如log_time、ip_addr、order_no），就算“不重复”。它解决不了逻辑膨胀，只是事后擦除，还可能掩盖真实问题。

例如：SELECT DISTINCT u.id, u.name FROM users u LEFT JOIN t_log l ON u.id = l.user_id看似去重，但一旦加上l.log_time，重复立刻回来；在某些引擎中DISTINCT还会触发隐式排序，大表查询明显变慢。

• DISTINCT必须紧贴SELECT，不能写成SELECT DISTINCT a.* FROM (...（多数旧版本报错）
• 只对明确需要去重的列用DISTINCT，比如SELECT DISTINCT user_id, name，而非DISTINCT *
• DISTINCT可能把本该区分的合法组合也合并——同一用户在不同渠道下的两笔相同金额订单，DISTINCT *会当成重复删掉

怎么让右表只输出你需要的那一行？

核心是控制右表的输出粒度，而不是在结果上“打补丁”。选哪种方式，取决于你要什么：

• 要汇总值（如登录次数、最新IP）：用子查询+GROUP BY预聚合
  SELECT u.id, u.name, p.cnt, p.max_ip FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt, MAX(ip_addr) AS max_ip FROM t_log GROUP BY user_id) p ON p.user_id = u.id
• 要完整单条明细（如最新一条日志）：用ROW_NUMBER()窗口函数，且rn = 1必须写在ON条件里
  ON p.user_id = u.id AND p.rn = 1——写在WHERE会丢掉没日志的用户
• 只判断“有没有关联记录”：改用EXISTS，逻辑清晰、无重复、性能更好
  SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM t_log l WHERE l.user_id = u.id)

LEFT JOIN + IS NULL为什么会漏数据或误匹配？

想查“没关联到子表的主表记录”，常写LEFT JOIN ... WHERE sub.id IS NULL。但如果子表有多条匹配记录，LEFT JOIN仍会产生多行，再用WHERE过滤时逻辑没问题，但容易忽略：若子表本就允许空值或存在重复键，IS NULL可能匹配出意料之外的行。

• 确保子表关联字段有唯一约束（如payment.order_id应为外键+唯一索引），否则LEFT JOIN天然导致主表膨胀
• 避免在ON条件里写AND sub.status = 'success'后又用WHERE sub.id IS NULL——这会把status不是success的也当“缺失”，应改用子查询或CASE WHEN
• WHERE条件写在JOIN后却过滤右表字段（如WHERE l.status = 'active'），会把LEFT JOIN变成事实上的INNER JOIN；应改到ON子句：LEFT JOIN t_log l ON u.id = l.user_id AND l.status = 'active'

真正容易被忽略的一点：JOIN后的结果集，已经不是原始左表的行集合了。哪怕你只SELECT左表字段，中间生成的临时结果也已被右表“撑开”——一旦把它当唯一实体继续操作，错误就埋下了。