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_amount FROM orders o LEFT 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.addr
FROM users a
LEFT 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拉，业务语义就断了。
