SQL 聚合前为什么要先对子表预汇总

顾言

发布时间：2026-08-24| 201人浏览过

原创

前言

在 SQL 里，`LEFT JOIN` 后直接做 `SUM`、`COUNT` 是最常见、也最容易被忽略的统计陷阱之一。本文从“为什么会翻倍”讲到“为什么预汇总更快”，再补上 `DISTINCT` 的误区、过滤条件该放哪、CTE 和子查询怎么选，帮助你判断什么场景必须先把子表压到正确粒度再做关联。

很多人第一次遇到 LEFT JOIN 后 SUM 翻倍，都会怀疑是不是 SQL 写法有坑，或者数据库算错了。其实问题出在聚合粒度：只要主表一行能匹配子表多行，JOIN 之后参与计算的就已经不是“原始业务行”，而是被展开过的中间结果集。要想把统计结果算准，同时控制中间数据量，关键做法就是先对子表按关联键预汇总，再把结果回连到主表。

为什么 LEFT JOIN 后 SUM 会翻倍

根本原因很简单：当主表的一行关联到子表的 N 行时，JOIN 会先把这一行复制成 N 行，再交给后面的聚合函数处理。于是 SUM、COUNT 统计的其实是“物理展开后的行数”，结果自然会被放大。

这不是数据库 bug，而是关系代数的正常行为。比如要查“每个用户的订单总金额”，如果你在 users LEFT JOIN orders 之后直接写 SUM(orders.amount)，看起来像是在按用户求和，实际上是在对 JOIN 后的明细行求和。只要后续还接了别的明细表，放大效应会更明显。

为什么会出现重复累加

可以把它理解成两步：

展示 LEFT JOIN 后明细行扩张以及预汇总后按 user_id 回连的对比信息图 — **先 JOIN 再聚合 vs 先预汇总再 JO**先汇总再 JOIN，核心是把子表压到与统计口径一致的粒度，再参与关联。

先做 JOIN，得到展开后的结果集。
再做 SUM、COUNT 等聚合。

也就是说，聚合函数并不知道哪一行是“业务上重复出来的”，它只会老老实实对当前结果集逐行计算。

正确做法：先对子表预汇总再 JOIN

避免重复统计的常用方式，是先在子查询里对子表按关联键聚合，让每个逻辑单位只保留一行，再去和主表做 LEFT JOIN。这样外层 JOIN 时，子表已经不是明细表，而是“每个用户一行”的汇总结果。

SELECT user_id, SUM(amount) AS total_amount
FROM orders
GROUP BY user_id

这个子查询的意义在于：先把 orders 压缩到 user_id 粒度，再交给外层查询使用。外层如果要保留没有订单的用户，还需要配合 COALESCE 把空值补成 0。

SELECT
  u.id,
  COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
  SELECT user_id, SUM(amount) AS total_amount
  FROM orders
  GROUP BY user_id
) AS o
  ON u.id = o.user_id;

这类子查询要满足的几个条件

子查询只返回“分组键 + 聚合值”，例如：SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id
外层 JOIN 键必须严格对应这个分组键
子查询必须带别名，MySQL 中常见的 Error Code: 1248，很多时候就是漏了 AS t

过滤条件为什么要写在子查询内部

如果只统计已支付订单，像 WHERE status = 'paid' 这种条件，应该写在预汇总子查询里。原因是它决定了“参与聚合的明细范围”，属于子表内部逻辑。

展示 DISTINCT 与预汇总在统计语义和性能上的差异信息图 — **DISTINCT 的适用边界**`DISTINCT` 只能解决部分重复计数问题，金额汇总场景仍应回到预汇总。

SELECT
  u.id,
  COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
  SELECT user_id, SUM(amount) AS total_amount
  FROM orders
  WHERE status = 'paid'
  GROUP BY user_id
) AS o
  ON u.id = o.user_id;

如果把这个条件挪到外层 WHERE，就会把原本用于“保留主表全部记录”的 LEFT JOIN 语义破坏掉，实际效果更接近 INNER JOIN。

为什么预汇总还能明显降低开销

预汇总不仅是为了算对结果，也常常直接决定 SQL 能不能在大表场景下跑得动。

假设三张都是百万级的明细表，直接 JOIN 之后，中间结果可能膨胀到上千万行；但聚合本身往往只需要一次扫描。把 SUM 放在 JOIN 之后，相当于先让数据库把所有组合都拼出来，再去统计。反过来，如果先按 user_id 或 order_id 汇总，每个逻辑单位只保留一行，中间结果集就会从千万级压缩到百万级甚至更少。

所以“先汇总再 JOIN”本质上是在主动控制聚合粒度和中间数据规模，而不是单纯多写几行 SQL。