SQL多表汇总实战：JOIN、UNION与CTE的完整指南-代码聚汇网

SQL多表汇总实战：JOIN、UNION与CTE的完整指南

绵羊料理·2026-08-29·阅读 23 GEO检测（免费）

SQL多表汇总JOINUNION

|难度：普通|阅读约 39 分钟

做SQL开发时间久了会发现一个规律：单表查询基本是送分题，真正的日常硬仗全在多表汇总。无论是做报表、跑数、搭数据看板，还是应付面试里那道经典的"请用一条SQL查出每个分类的销售总额"，核心就一句话——把两张甚至七八张表的内容，按正确的逻辑合并成一堆有用的数据。这篇文章从"两个表"讲起，一步步扩展到多个表，把JOIN、UNION、子查询、CTE这些手段串起来，结合真实业务场景说清楚每一步为什么要这样写。

读这篇文章，你带走的不是几个孤立的SQL片段，而是一套多表汇总的完整思路。适用人群很明确：刚学会单表增删改查、想进阶SQL查询能力的开发者和数据分析师，也可以在面试前把它当作复习提纲。我会用同一个订单业务示例贯穿全文，这样你能清楚看到同一个业务需求，随着参与的表数量增多，SQL是怎么一步步长成完整形态的。

1. 动手之前的思路梳理：多表汇总到底在做什么

1.1 两种汇总方式的本质区别：UNION 和 JOIN 别搞混

很多新手一提"多表汇总"，第一反应就是JOIN。其实汇总这个动作在SQL里有两种完全不同的方向，搞混了，需求就理解偏了一半。

纵向汇总（UNION）：把多张表的"行"上下拼接。比如1月的订单表有50万行，2月的订单表有60万行，UNION ALL之后得到110万行。这些表的列结构基本一致，合并的目的是"堆在一起"。
横向汇总（JOIN）：把多张表的"列"左右拼接。比如用户表有用户姓名，订单表有订单金额，按用户ID把列拼成一行，得到"哪个用户买了多少钱"的完整宽表。

我平时带团队做数据需求，常用一个生活化类比来说明这两者的区别：UNION像是把班级里分成两组同学的名单按顺序贴在同一张纸上，JOIN像是把学生的基本信息表和成绩表按学号装订成一本完整档案。很多需求方说"帮我汇总一下"，实际上要的是不同月份数据的堆叠，这时候应该用UNION ALL而不是JOIN。

这里还要提醒一个细节：UNION和UNION ALL有区别，UNION会去重，UNION ALL不去重。在汇总场景中，如果明确知道两个结果集没有重叠，或者重叠也不影响业务判断，优先用UNION ALL，性能比UNION好不少。因为UNION背后要额外做排序去重，数据量越大，这个代价越明显，我见过一个跑全量数据的UNION查询，改成UNION ALL后耗时直接从30秒降到8秒。

1.2 先弄清楚表与表之间的关系：一对一、一对多还是多对多

在写JOIN之前，最好先在纸上把要连接的表之间的关系画出来，这决定JOIN之后结果集的行数。

一对一：A表一行对应B表一行，比如用户表和用户扩展信息表，都以user_id关联。JOIN之后行数基本不会变多。
一对多：A表一行对应B表多行，比如一个订单(order)对应多条订单明细(order_items)。JOIN之后，A表的每一行会被复制成B表匹配行数那么多行。这是数据翻倍危机的根源。
多对多：A表多行对应B表多行，比如学生表和课程表通过选课表关联。直接JOIN会产生大量组合行，通常需要先聚合，或者通过中间表细化逻辑。

我面试候选人的时候，第一道SQL题就爱问"订单表和订单明细表LEFT JOIN，结果行数比订单表多，这是怎么回事？"很多人答不上来。其实原因很简单：订单表一行对应明细表多行，连接后行数被放大是正常现象，不算错误。但如果你的业务目标是"查每个订单的信息"，明细表里的多条明细会把订单信息重复展示，这时就要考虑是不是应该先按订单汇总明细表的金额，再和订单表做关联。

1.3 选好"主表"：内连接还是外连接，由业务口径决定

JOIN中的INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN，本质区别是"保留哪些行"。实际开发中，我建议用一个决策思路来确定方向：

先问自己：哪张表是核心？我要保证这张表的所有记录都出现在结果里。
如果要保留A表所有行，就用LEFT JOIN（A表写在左边）。如果要保留B表所有行，就用RIGHT JOIN，不过很多工程师习惯把B表写在左边再用LEFT JOIN，逻辑等价，代码可读性更好。
如果只想要两边都匹配上的行，用INNER JOIN。
如果要保留两边所有行，用FULL OUTER JOIN，但MySQL原生不直接支持，得用LEFT JOIN UNION RIGHT JOIN来模拟。

使用场景举例：查"所有用户及其订单"，即使没下过单的用户也要出现在结果里，那就以用户表为主，用LEFT JOIN订单表。查"所有订单及其下单用户"，如果订单表里不会存不存在的外键，用INNER JOIN就够；但如果数据质量差，存在脏数据，你又想看到那些"订单还没有对应用户"的问题单，就可以考虑以订单表为主做LEFT JOIN用户表。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从两个表起步：JOIN写法与行数变化规律

2.1 最小可用的INNER JOIN示例

先看最常见的场景：用户表和订单表，查询每个订单对应的用户名和订单金额。

sql复制SELECT o.order_id, o.order_date, o.amount, u.name
FROM orders o
INNER JOIN users u ON o.uid = u.uid;

这个查询做了三件事：从orders表选出订单字段，从users表取出用户名，用uid这个关联条件把两边行匹配起来。ON后面的关联字段，最好是两边都有索引的列，否则一旦数据量大，优化器只能做嵌套循环加全表扫描，性能会很差。

写多表查询时，我强烈建议给每张表起一个有业务含义的别名。orders表用o，users表用u，order_items表用oi，这样SQL一旦长了，别人读起来不会晕。如果两个表存在同名字段，比如都有uid，SELECT时不要只写uid，一定要带表别名前缀如o.uid、u.uid，否则数据库会报列名歧义的错误，就算不报错，结果也可能不是你想要的。

2.2 LEFT JOIN：想让主表记录不丢，就这么写

如果需求变成"查所有的用户以及他们下过的订单，没下过单的用户订单字段显示NULL"，那就把INNER JOIN换成LEFT JOIN。

sql复制SELECT u.uid, u.name, o.order_id, o.amount
FROM users u
LEFT JOIN orders o ON u.uid = o.uid;

INNER和LEFT的结果差异很关键：INNER只显示有订单的用户，LEFT会显示所有用户，没有订单的用户，订单字段补成NULL。这里NULL要特别重视，它表示"没有匹配到"，和真实值为0是有区别的。比如统计报表里，NULL可以理解为"该用户从未下单"，0则是"有下单记录但金额为零"，两者在业务上含义完全不同，后面做SUM时也要提前用COALESCE处理，避免NULL把聚合结果也带成NULL。

2.3 一对多连接导致的数据翻倍，怎么应对

接下来看一个我在前面反复提到的问题：一对多连接导致数据翻倍。具体SQL长这样：

sql复制SELECT o.order_id, o.amount, i.product_name, i.quantity
FROM orders o
LEFT JOIN order_items i ON o.order_id = i.order_id;

如果订单A包含3个商品，结果里订单A的order_id和amount就会重复出现3次。这个结果在明细级查询是正确的，但如果有人误拿这个结果去SUM(o.amount)，订单A的金额就会被加3次，统计结果直接错掉。

正确的应对方式之一是：先聚合明细表，再连接主表。

sql复制SELECT o.order_id, o.amount, t.total_quantity
FROM orders o
LEFT JOIN (
    SELECT order_id, SUM(quantity) AS total_quantity
    FROM order_items
    GROUP BY order_id
) t ON o.order_id = t.order_id;

子查询先算出每个订单的明细总件数，然后再和订单表按order_id一对一连接，结果行数就和订单表一致了。这种"先聚合再JOIN"的写法，多表汇总里出现频率极高，我几乎每天都会用，建议直接养成习惯。

2.4 什么时候用RIGHT JOIN和FULL OUTER JOIN

说实话，我在实际项目里主动写RIGHT JOIN的次数屈指可数，因为可读性不如把表的顺序换一下，统一用LEFT JOIN。但别人写的代码里可能遇到，你得能看懂。FULL OUTER JOIN在MySQL里不支持，在PostgreSQL、SQL Server、Oracle里可以用。MySQL下的替代写法是用UNION把两个方向连接的结果拼起来：

sql复制SELECT u.uid, o.order_id
FROM users u
LEFT JOIN orders o ON u.uid = o.uid
UNION
SELECT u.uid, o.order_id
FROM users u
RIGHT JOIN orders o ON u.uid = o.uid;

UNION自带去重，如果两个方向的结果集基本没有重复，用UNION ALL效率更高。这种语法差异在很多老项目里很常见，热词里sql server 2008 r2、sql server 2012 express这类下载词热度一直很高，说明还有大量系统跑在老版本数据库上，写多表SQL时不仅要考虑业务逻辑，还得考虑数据库版本的语法上限。

3. 从两个表扩展到多个表：JOIN、UNION与CTE的组合

3.1 多表JOIN的写法和连接顺序

从两张表到多张表，不是简单地在SQL后面多接两个JOIN就完事，思路要清晰。多表JOIN的基本语法是：

sql复制SELECT ...
FROM a
JOIN b ON a.key = b.key
JOIN c ON b.key2 = c.key2
JOIN d ON a.key3 = d.key3;

关键不是把表A、B、C、D一股脑塞进去，而是先把JOIN关系拆解成两两之间的关联。我习惯从主表出发，一张表一张表地往上挂，每挂一张表，就在心里推演一次行数变化。比如orders和order_items是一对多，行数会放大；orders和users是多对一，行数保持不变。逐个确认过后，最后的结果行数才心里有底。

连接顺序对大多数优化器来说会被自行调整，SQL语句里表的先后顺序不直接决定最终执行顺序，但影响人读代码的思路。我的经验是：哪张表是业务主体，就把它放在FROM后第一个位置，其余表按关联路径逐级排列，这样排查问题的时候，能顺着业务逻辑一路看下来。

3.2 用UNION把多个结果集纵向汇总

多表汇总不只是JOIN一种手段。比如业务上有好几个订单来源：正式订单表、退款单表、手工补录表，它们的列结构相同，要把它们全部汇总到一个结果集里，就用UNION ALL：

sql复制SELECT order_id, amount, '正常订单' AS source FROM orders
UNION ALL
SELECT order_id, amount, '退款单' FROM refunds
UNION ALL
SELECT order_id, amount, '手工补录' FROM manual_orders;

这里有几个硬性要求：每个SELECT出来的列数量必须一致，类型要兼容，列名以第一个SELECT为准。我在实际项目里吃过一次亏：第三段SELECT忘了补列，结果SQL直接报错，因为三段查询的列数不一致。

还有UNION不带ALL时的去重坑，我踩过不止一次。两个表里恰好有相同的order_id，本来业务上需要保留两条记录，结果UNION去重成了一条，数据就这么悄悄变少了。所以除非你明确要"去重后的合集"，否则汇总场景一律用UNION ALL。

3.3 用CTE（WITH AS）拆解复杂多表逻辑

多表汇总一旦超过4张表，SQL很容易变成一坨难以维护的代码。我建议使用公共表表达式，也就是常说的CTE。它允许你把一个复杂的汇总拆成几个清晰步骤，每一步结果都命名，后续可以反复引用。

sql复制WITH order_amount AS (
    SELECT order_id, SUM(amount) AS total_amount
    FROM orders
    GROUP BY order_id
),
user_order_summary AS (
    SELECT u.uid, u.name, COUNT(o.order_id) AS order_count,
           COALESCE(SUM(o.amount), 0) AS total_amount
    FROM users u
    LEFT JOIN order_amount o ON u.uid = o.uid
)
SELECT * FROM user_order_summary;

CTE最大的价值是让逻辑步骤显式化：第一步先算每个订单的总金额，第二步再汇总到用户维度。排查问题时，每一段都能单独拿出来执行验证，不像一个长SQL从头跑到底，出错了都不知道是在哪一步翻车。MySQL需要8.0及以上版本才支持CTE，SQL Server从2005就有，Oracle和PostgreSQL也早就支持。如果公司数据库版本太老，就只能用子查询或临时表代替，这也是为什么我经常劝别人，别把老版本数据库当成永远的舒适区。

3.4 先聚合后连接 vs 连接后聚合：性能与正确性怎么选

多表汇总里有个经典选择题：到底先聚合再连接，还是先连接再聚合？

拿"查每个分类的销售总额"举例。写法A是先连接再聚合：

sql复制SELECT c.category_name, SUM(oi.quantity * oi.price) AS sales_amount
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
JOIN categories c ON p.category_id = c.category_id
GROUP BY c.category_name;

写法B是先聚合再连接：

sql复制SELECT cat.category_name, t.sales_amount
FROM (
    SELECT p.category_id, SUM(oi.quantity * oi.price) AS sales_amount
    FROM order_items oi
    JOIN products p ON oi.product_id = p.product_id
    GROUP BY p.category_id
) t
JOIN categories cat ON t.category_id = cat.category_id;

两种写法结果一样，A更直观，B更好控制中间结果集的大小。性能上，如果先通过WHERE过滤掉大量行，那就先过滤再连接，这样参与JOIN的数据量会小很多。我自己的经验是：遇到一对多关系，如果要对"一"那一侧的字段做聚合，很容易出现重复累加，这时候宁可写复杂一点，先聚合，也不要在连接后对非明细侧的字段直接SUM。

4. 实战案例：订单汇总从2张表做到5张表

4.1 业务场景设计

为了把前面这些知识点串起来，我设计一套贯穿式的业务场景，表结构如下：

users(user_id, name)：用户表
orders(order_id, user_id, order_date, status)：订单表
order_items(item_id, order_id, product_id, quantity, price)：订单明细表
products(product_id, product_name, category_id)：商品表
categories(category_id, category_name)：商品分类表

需求是做一个"每个用户、每个商品分类的订单汇总报表"，输出用户姓名、分类名称、订单数量、销售总额。这个需求在电商后台非常常见，也是我经常拿来考刚入职数据分析师的实操题。

4.2 第一阶段：先写两表连接，把明细数据跑出来

从最核心的两张表开始：orders和order_items，因为销售明细数据在明细表里。这个阶段的目标是先拿到"订单-商品明细"的底层数据。

sql复制SELECT o.order_id, o.user_id, oi.quantity, oi.price
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id;

这阶段可以先验证一下：订单表有100个订单，明细表有300条明细，那查询结果大概有300行，因为一对一的关系在这里变成了一对多。跑通这个查询后，再往上加维度表。

4.3 第二阶段：扩展用户与商品维度

先挂用户表，拿到订单对应的用户姓名：

sql复制SELECT u.name, o.order_id, oi.quantity, oi.price
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN users u ON o.user_id = u.user_id;

再继续挂商品表和分类表，补上商品名和分类名：

sql复制SELECT u.name, c.category_name,
       oi.quantity, oi.price
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN users u ON o.user_id = u.user_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories c ON p.category_id = c.category_id;

到这里已经是4个JOIN、5张表了，但SQL结构依然清楚，因为每加一张表都只做一件事：把需要用到的维度列扩展进来。这也是我建议渐进式开发SQL的原因，每加一张表，结果都能单独验证，一旦出问题，能很快定位到是哪一步引入的。

4.4 第三阶段：加聚合，实现报表需求

现在把明细数据按"用户 + 分类"分组聚合：

sql复制SELECT u.name, c.category_name,
       COUNT(DISTINCT o.order_id) AS order_count,
       SUM(oi.quantity * oi.price) AS sales_amount
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN users u ON o.user_id = u.user_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories c ON p.category_id = c.category_id
GROUP BY u.name, c.category_name;

这里有一个非常容易踩的坑，我特意在SQL里用了COUNT(DISTINCT o.order_id)而不是COUNT()。原因是订单明细是多行，如果一个订单包含多个商品，COUNT()会把同一个订单计数多次，而业务上"订单数量"显然应该按订单维度去重。用COUNT(DISTINCT order_id)才能得到真实订单数。销售总额的计算是SUM(quantity * price)，这个字段来自明细表，行数放大不影响它的总和，所以可以直接SUM。

4.5 第四阶段：用CTE让长SQL更清爽

上面那个SQL已经有点长了，如果后面还要继续叠加更复杂的逻辑，比如加筛选条件、再关联一张门店表，那SQL会越来越难读。用CTE拆一下：

sql复制WITH order_detail AS (
    SELECT o.user_id, o.order_id, p.category_id,
           oi.quantity * oi.price AS line_amount
    FROM orders o
    JOIN order_items oi ON o.order_id = oi.order_id
    JOIN products p ON oi.product_id = p.product_id
),
user_category_sales AS (
    SELECT user_id, category_id,
           COUNT(DISTINCT order_id) AS order_count,
           SUM(line_amount) AS sales_amount
    FROM order_detail
    GROUP BY user_id, category_id
)
SELECT u.name, c.category_name, s.order_count, s.sales_amount
FROM user_category_sales s
JOIN users u ON s.user_id = u.user_id
JOIN categories c ON s.category_id = c.category_id;

这个版本读起来就像在逐层剥洋葱：先做明细层，再做汇总层，最后做维度补全。排查问题也变得非常直接——订单数不对，就单独跑一下user_category_sales那段；用户名不对，就查最后一段。这种递进式开发SQL的方法，我每天都在用，强烈推荐你也试试。

5. 多表汇总的常见问题排查与性能优化实录

5.1 结果集行数莫名暴涨，先查连接键是否有重复

现象：两表LEFT JOIN返回的行数远超过主表行数。

排查思路：检查JOIN的关联字段在副表是否存在重复值。比如users表LEFT JOIN orders表，如果orders表里同一个user_id有多条记录，行数翻倍是正常现象。但如果业务目标是一个用户一行，那就得先对orders表按user_id做聚合再连接。

可以这样快速验证：

sql复制SELECT COUNT(*) FROM users;
SELECT COUNT(DISTINCT user_id) FROM orders;
SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.user_id = o.user_id;

第一个数和第三个数差异很大，就说明orders表里有重复的user_id。多表场景下，这种问题尤其隐蔽，因为可能是某一张中间表在连接时产生了重复，导致后面所有维度的行数都膨胀了。我的习惯是每连一张表，就检查一次行数变化，逐张定位到元凶。

5.2 连接后出现大量NULL，导致SUM结果为NULL

多表JOIN之后，如果某一行没有匹配，外连接的一侧字段会是NULL。如果在NULL上做SUM，结果很可能是NULL或者不符合预期。解决办法是用COALESCE提前把NULL转成0。

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

这句里的COALESCE(sum_amount, 0)，逻辑是：用户没下过单，金额显示0而不是NULL。NULL和0在报表里含义不同，一个表示"没有记录"，一个表示"有记录但金额为零"。写报表需求时，要提前和需求方确认清楚，他要的是哪一种展示。

5.3 JOIN速度慢，优先查索引

多表JOIN性能问题八成出在关联字段没有索引。看执行计划的时候，如果发现连接列出现大范围全表扫描，或者出现Using join buffer，基本就是索引问题。

需要建索引的列通常包括：

外键列，比如orders.user_id、order_items.order_id、order_items.product_id
WHERE条件里频繁使用的列
参与GROUP BY、ORDER BY的列

索引带来的提升往往是数量级的。我曾经在订单表上建过(user_id, order_date)复合索引，原来几秒钟的统计查询，加完索引能降到几百毫秒。还有一个常见的反模式：在关联字段上套函数，比如ON DATE(o.order_date) = DATE(p.pay_date)，这样索引直接失效。优化器很难对函数处理后的结果用索引，最好在写入数据时就保证关联列格式一致，或者在表里冗余一个同一格式的列。

5.4 排查慢SQL的常规动作

遇到慢SQL，我的流程是先看执行计划，而不是瞎猜。MySQL用EXPLAIN，SQL Server看实际执行计划，Oracle用AUTOTRACE或dbms_xplan。重点看这几个指标：

type字段：从system、const、eq_ref、ref到ALL，性能依次递减。ALL代表全表扫描，大表上就要警惕。
key字段：实际用到的索引。如果是NULL，说明没用到索引。
rows字段：预估扫描行数。两个表JOIN时，如果预估扫描行数差异很大，说明优化器可能选错了驱动表。

实际经验里，我看到最多的慢JOIN问题，就是关联列没有索引。把索引补上，SQL的执行计划会立刻好看很多。其次是查询条件写法有问题，比如在关联列上做函数计算、隐式类型转换，这些都会让索引失效，属于典型的"字段没写错，但索引用不上"的情况。

5.5 多表汇总时的去重问题

去重也是热词里反复出现的需求，比如"sql语句去重查询"、"清洗sql语句去重"。多表汇总时的去重，往往不是简单用DISTINCT，而是"按某个维度取一条"。比如查"每个用户的最新一笔有效订单"，用窗口函数ROW_NUMBER()最合适：

sql复制WITH ranked AS (
    SELECT o.order_id, o.user_id, o.amount,
           ROW_NUMBER() OVER (PARTITION BY o.user_id ORDER BY o.order_date DESC) AS rn
    FROM orders o
    WHERE o.status = 'valid'
)
SELECT * FROM ranked WHERE rn = 1;

这条SQL的思路是：先把每个用户的订单按时间倒序编号，然后只取编号为1的那行。把它改造成多表汇总也很容易，只要在ranked那个CTE里把需要的维度表提前JOIN进来就行。MySQL 8.0以上原生支持窗口函数，SQL Server和PostgreSQL也支持，窗口函数在"分组取TOP N"场景比子查询写得清晰得多。

5.6 慢SQL优化专题：多表JOIN还能怎么救

多表汇总的慢SQL，除了索引，还有几条常规优化手段：

先过滤再连接，是效果最立竿见影的。WHERE条件提前到子查询里，让每张表先把这个月的数据筛出来，再参与JOIN，中间结果集能小一大圈。我处理过一个真实案例：一段5张表JOIN全量数据的SQL要跑40分钟，唯一改动就是把业务时间范围推到每个子查询里，SQL时间直接降到2分钟。

避免SELECT *。多表JOIN时，SELECT出来的是最终要落地的宽表，只选需要的列可以减少网络传输和临时表空间，尤其当结果集有几百万行时，差别非常明显。

必要的时候分步执行。有些复杂的多表汇总，一步写完不仅难调，性能也差。可以先创建临时表，把中间结果落下来，再继续下一步。报表系统里常见的做法是先把明细汇总到临时表，再和维度表关联，分步比一步到位往往更可控。

6. 写在最后：多表汇总的实操心得

多表汇总这件事，做得多了你会发现，真正难的永远不是SQL语法，而是逻辑拆解。我个人的习惯是，拿到需求先不急着敲键盘，把涉及的表、表之间的关系、主表是谁、连接方向是什么，先在草稿纸上画清楚。画明白了，SQL基本上就是照着关系图翻译一遍而已。

另一个很重要的习惯是渐进式开发。不要试图一次写出一条20行的JOIN，然后祈祷它能一次跑通。先写两表，验证行数；再加一张表，再验证；最后补聚合和维度。每一小步都可以用LIMIT 10或者COUNT(*)快速检查，问题会被扼杀在萌芽状态，而不是到最后面对一大坨SQL无从下手。

最后再分享一个小技巧：多表汇总的SQL写完，一定要保留一个"调试版"——把聚合条件先去掉，直接输出明细行，用来核对JOIN关系是否正确。我见过太多报表数据对不上，最后发现是JOIN方向写反了或者少了一个关联条件。保留明细版SQL，下一次数据对不上时，你就能快速定位是JOIN的问题，还是聚合口径的问题。这套"明细验证 + 逐步加表 + 提前聚合"的组合方法，我在实际项目中用了很多年，希望对你有用。