如何解决SQL使用LEFT JOIN时右表含多条记录导致的数据发散？

LEFT JOIN后SUM翻倍或COUNT虚高，根本原因是右表关联键不唯一导致行膨胀，必须将聚合前置到JOIN前；正确做法是用子查询按业务主键预聚合右表再LEFT JOIN，或用ROW_NUMBER()取单条记录，同时确保右表过滤条件写在ON而非WHERE中。

LEFT JOIN后SUM翻倍或COUNT虚高，一定是右表一对多没处理

数据发散不是LEFT JOIN的bug，是它严格按行拼接的必然结果。只要右表关联键（比如order_id、user_id）不唯一，左表一行就会被复制成N行——后续所有聚合函数都基于这N行计算，SUM()自然放大N倍，COUNT(*)也虚高。

常见错误是直接在JOIN后加GROUP BY，但此时分组对象已是膨胀后的中间结果，无法还原业务语义。必须把聚合逻辑前置到JOIN之前。

• 先确认右表是否真存在重复：查SELECT count(*), count(DISTINCT key_col) FROM right_table，若两者不等，说明有重复
• 明确业务需求：是要“每个左表记录只连一条右表记录”，还是“汇总右表所有匹配项”？前者用去重，后者用预聚合
• 别依赖DISTINCT救场——它只能去最终结果的行，不能阻止中间膨胀，性能差且语义模糊

用子查询先聚合再LEFT JOIN，最通用稳妥

把右表按业务主键（如order_id）预先聚合，生成单行结果，再JOIN。这样左表每行只匹配一次，彻底规避发散。

例如订单明细表关联订单主表，要算每单总金额：

SELECT o.order_id, o.order_date, d.total_amountFROM orders oLEFT JOIN (  SELECT order_id, SUM(amount) AS total_amount  FROM order_items  GROUP BY order_id) d ON o.order_id = d.order_id

注意点：

• GROUP BY字段必须是JOIN条件中使用的字段，且和左表主键严格对应
• 聚合函数选SUM、COUNT还是MAX，取决于业务：要最新状态用MAX(update_time)，要标签列表用STRING_AGG(tag, ',')（PostgreSQL）或GROUP_CONCAT（MySQL）
• 如果右表数据量大，务必给GROUP BY字段建索引，否则子查询本身就会慢

只取右表一条记录时，用ROW_NUMBER() + 窗口函数过滤

当业务只需要右表任意一条（如最新、最高优先级、最早创建）记录，而不是全部汇总，用ROW_NUMBER()比聚合更轻量。

Oracle/PostgreSQL/SQL Server都支持，MySQL 8.0+同样可用：

SELECT a.*, b.phone, b.addrFROM users aLEFT JOIN (  SELECT *,         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY update_time DESC) AS rn  FROM contact_info) b ON a.user_id = b.user_id AND b.rn = 1

关键细节：

• PARTITION BY必须是JOIN用的外键字段，ORDER BY决定哪条“胜出”，DESC通常取最新
• 不能把WHERE b.rn = 1写在子查询外层——那样LEFT JOIN会失效，左表无匹配时整行丢失
• 如果右表该字段有NULL，ORDER BY需显式写NULLS LAST（PostgreSQL）或用COALESCE兜底，否则排序不可控

WHERE里写右表条件，LEFT JOIN就变INNER JOIN

这是最隐蔽也最常踩的坑：WHERE t2.status = 'active'会让所有右表为NULL的左表记录被过滤掉，效果等同于INNER JOIN。

正确做法永远是把右表筛选条件塞进ON子句：

LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'active'

如果业务真要区分“有活跃订单的用户”和“全部用户”，就得拆成两个逻辑——要么用CTE分别聚合，要么用CASE WHEN在SELECT里做条件计数，而不是靠WHERE硬筛。

复杂点在于多表级联时，ON条件的层级容易错乱。比如t1 LEFT JOIN t2 ON ... LEFT JOIN t3 ON t1.id = t3.t1_id，这里t3只认t1，不感知t2的过滤结果。若t2已筛过数据，t3却仍从全量t1拉，业务语义就断了。