LEFT JOIN 之后，SUM 翻倍、COUNT 虚高，这种问题几乎每个用 SQL 的人都碰到过。根本原因其实很简单：右表的关联键不唯一，导致左表每行被复制成了多行，后续所有聚合函数都基于膨胀后的数据计算，结果自然就失真了。这不是 LEFT JOIN 的 bug，而是它严格按行拼接的必然结果——只要右表关联键（比如 order_id、user_id）有重复，左表一行就会被复制成 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 拉，业务语义就断了。
